Messages in this thread | | | Date | Sun, 13 Aug 2000 18:36:31 -0400 (EDT) | From | Christopher Vickery <> | Subject | Re: NTFS-like streams? |
| |
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/
| |