Re: [Linux-ntfs] Re: [Linux-NTFS-Dev] Re: ANN: NTFS new release available

[Martin von Loewis]

> 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?

Regards,
Martin