At 13:53 27/05/2001, Martin von Loewis wrote:
> > Yes and no. They will be uncompressed but not when opening the inode. It
> > will be "uncompress required extent's run list on demand".
>
>Are you sure this can work?
No.
>Initially, I thought I could use the attribute list to only uncompress the
>extend that has the VCN I'm interested in.
Same idea here.
>That would not work: NT would split individual runs across extends
>(i.e. split them in the middle).
Argh! That seems really stupid thing to do, as it makes it difficult to
interpret what the highest_vcn/lowest_vcn field of attribute extents is
supposed to mean!?!
This does however explain some of the code uglyness I have seen (and chosen
to ignore) in the ntfs.sys disassembly run list handling...
>Did I misunderstand, or do you have a solution for that as well.
No solution. I wasn't aware this could happen. I knew a compression block
could be split in it halves but I didn't realize this braindamaged
complication.
I guess we will have to decode the whole run list in one go then. Anything
else would be slower over all. - What we could do of course is to walk the
mapping pairs array real quick not reading the numbers only to get the
correct starting offset into the next extent and then only decode that one
but that would mean walking the mapping pairs array repeatedly (once to get
each extent) which would be overall slower than just getting the lot at
once. - I maintain that we should do this on demand and not on inode open,
though. - I will have another think about this, but if it is true that NT
splits the records anywhere, then it would be impossible to start at any
extent other than the first one.
Anton
--
"Nothing succeeds like success." - Alexandre Dumas
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
