[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectHandling file forks in page cache?
Hi all,

I'm playing around with a new implementation of the NTFS driver, and have
come up with a problem: how to handle file forks in the page cache? (`file
with forks' meaning file with multiple data streams, or attributes as NTFS
seems to want to call them). The following options spring to mind at the moment,
comments would be appreciated:

i) extend the current page cache implementation to deal with forked files.
Apart from the hassle and code-cleanliness issues, I'm worried that doing
this might encourage people to implement file forks in other filesystems,
which I don't think is a good idea :-(

ii) re-implement as much of the page cache as required in the driver, and make
handle with forked files. Hmmm. Bloat.

iii) some sort of horrible kludge along the lines of: reserve part of the
inode number space to be (dynamically?) allocated to the non-data forks
of files / directories. This seems pretty dodgy as NTFS uses 48 bit
inode numbers; we can't guarantee we'd have enough `spare' on a 64 bit
architecture, let along on 32bit boxen. I can't see it working.

iv) as Windows NT currently only uses the non-data forks for metadata, store
the data fork in the page cache as normal, and read the metadata forks
directly. This isn't entirely simple as a lot of the metadata structures
can be bigger than a single block, but it should be do-able, right? I
guess this is the least nasty option, but I'd like comments..


No good deed goes unpunished.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.058 / U:2.304 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site