On Sun, 13 Aug 2000, Theodore Y. Ts'o wrote:
> So as much as I understand the desire for one API "to rule them them all
> and in the darkness bind them", I really believe that Extended
> Attributes are fundamentally different from Named Streams, and you
> really shouldn't try to stretch EA's over the Named Streams procrustean
> bed.
I was beginning to think that the "HPS can be implemented
using named streams but not vice-versa" argument would hold
sway. But, in agreement with your point, I notice that an
MFT entry in NFS (the equivalent of an inode) consists of 7
attributes:
Standard Information - DOS file attributes
Name - Well, this is NTFS, not Unix
Security Descriptor
Data - The data in this file's unnamed
stream
Named Data - There can be 0 or more Named Data
attributes - what we have been
calling "NTFS-like streams"
Index Root, Index Allocation, and Bitmap - Somehow these
structs allow individual 32KB
extents ("compression units") to be
compressed or not.
Reparse - Identifies a file system filter
that executes when this file or
directory is accessed. (You could
associate tarfs with a tar file,
for example.)
So it seems that a complete implementation of NTFS would
require all the features of other known filesystems.
(I suppose it's remotely possible that I don't know all the
features of all filesystems, and thus might be wrong, here.)
IF one were to change the design of the kernel to allow for
future support of arbitrary filesystems, it seems that
adequacy of support for NTFS would provide a guage for
evaluating the sufficiency of such design changes.
Of course, ioctl() allows anything to be accomplished, but
my understanding is that there is some sympathy for the
notion of providing a vfat=>fs api that allows a rich set of
filesystems to be implemented with a common programming
interface.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:32 EST