[NTLUG:Discuss] Re: mounting drives from other os -- NAS is also a good option

[Bryan J. Smith]

On Wed, 2004-09-22 at 13:50, Chris Cox wrote:
> No (for NTFS anyway).  Closest to navtive NTFS is "captive"
> http://www.jankratochvil.net/project/captive/  Which might
> work well for you.  But I'm not sure if it fits the "STABLE"
> requirement.

The "STABLE" problem is with NTFS itself.  In a nutshell, it is "unsafe"
to _ever_ write to a NTFS filesystem with _any_ OS installation that
anything but the OS instance that created it (even other _native_ NT 5.x
versions), because of the SAM-registry tie-in.  Using the LDM disk label
("dynamic disk"), instead of the legacy BIOS/DOS disk label ("standard
disk" -- primary/logical partition table) allows NT 5.x to store
SAM-registry information in hidden sectors.

But yes, Captive works pretty damn good _regardless_ of the disk label
-- as long as the NT installation is local and accessible.

Otherwise, the Linux-LDM support in the kernel is fairly good for the
NTFS kernel driver, and gets better at reading those hidden sectors
everyday.

> Hmmm... nfs has its own set of issues

NFS is UNIX-centric, presenting a _near-physical_ access as local. 
I.e., direct inode references.  It is _not_ a logical/virtual network
filesystem like SMB.  Hence why only Ext3 and XFS were the only 2
journaling filesystems that were kernel NFS compatible for the longest
time.

> and really eliminates any benefit of NTFS (for example) as the
> underlying filesystem.

Agreed.  Using NTFS is far worse.

> You'd be better off exporting it via Samba.  Though there will still
> be some limitations (even with 3.0 and 3.2).  Will require a bit
> of work and only fixes things better for Windows.
> Samba 4 will likely bring POSIX filesystems to Windows.  Then, finally,
> we'll have filesystems that can be shared with all perms, acls, etc.
> between truly open systems and Windows.

Samba 4 will require OS-specific kernel modules to do so.  From what I
saw a year ago, they will start taping the underlying VFS of the OS to
do so.  Which will make Samba 4 pretty OS-limited.

> Use FAT32 (again, no practical benefits to NTFS once shrouded with
> NFS.. epecially NFS).

NFS requires an inode filesystem.  Kernel NFS requires a traditional
inode structure, or massive workarounds (e.g., for ReiserFS and
OS/2-ported JFS -- Linux's JFS does _not_ come from AIX, for various,
legal reasons).

> If we're talking just file storage... it's
> pretty portable and more than enough for just files and dirs (in
> most cases).  This allows you to use usb/firewire, direct attached,
> or whatever.

Also consider UDF, which was designed _exactly_ for this thing. 
Unfortunately, you'll have to pay $$$ for a Windows driver that writes
(the stock only reads -- at least through 2000/XP).

> Consider a NAS solution (something that talks SMB) and let this
> be your abstraction layer (might as well use FAT32 though.. which
> could be NAS or whatever).

That is highly recommended by myself as well.  Consider building a
portable, FlexATX, MicroATX or small-footprint system for this very
purpose.

> Perhaps we need more information about what filesystem features
> you need that made you think you had to have NTFS or HFS+.

Agreed.

I'm kinda shocked how many people don't understand NTFS, and the
misconceptions.  Linux's NTFS limitations are not due to Linux, but NTFS
itself.  Microsoft designed it with a lot of "false security" that
prevents it from being writable by anything but the system that created
it.  Any MCSA/MCSE on 2000 should know this (but most are still NT 4).


-- 
Bryan J. Smith                                  b.j.smith at ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik