[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.034 / U:0.244 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site