Messages in this thread | | | Date | Fri, 23 Jul 1999 23:04:17 +0100 | From | Steve Dodd <> | Subject | Handling 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..
Thanks.
-- No good deed goes unpunished.
- 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/
| |