[lkml]   [2001]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Linux-ntfs] Re: [Linux-NTFS-Dev] Re: ANN: NTFS new release available (1.1.15)
> I would love to move inode metadata to the page cache. That would simplify 
> so much in the NTFS driver and would result in an incredible speed boost
> due to getting rid of all the silly copying of data back and forth inside
> the driver as we could just pass pointers around instead (to locked pages
> or other form of internal locking).
> No thank you. I would rather have it contiguous or at least logically
> contiguous. I don't care if the pages are physically contiguous as long as
> I can see them as one piece... I mean, ok, I could break up run lists, as
> they are arrays of fixed size structs and the boundary cases would be
> predictable

When you talk about avoiding copying, are you thinking of not copying
the runlists, as well? If so, how can you avoid uncompressing them?
That seems very complicated, plus you have to concatenate the pieces
of the runlist if they span multiple MFT records, anyway.

> They are not. They are derived from compressed on-disk structures (which
> are re-compressed when updating the inode). Runlists of such large size are
> only needed for A) huge files/directories, B) extremely fragmented
> files/directories, or C) a combination of A and B. (Remembering that
> metadata is stored as files, so the same applies for the metadata itself.)

I guess this answers my question - you will continue to uncompress the
runlist when opening the inode, right?

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

 \ /
  Last update: 2005-03-22 12:54    [W:0.193 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site