[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: file-finder : was(Re: JFFS - ready for submission into 2.?)
Bjorn Wesen wrote:
> It was over a year since I was involved in the design, but IIRC, version
> numbering is orthogonal to node placement in the file. Each node says
> where it starts in the file and the size says how huge chunk it
> So if there only is one node in the system for file A, with start pos 0
> and length 32768, then that is it. If there are two, the one with the
> highest version count is the right one. The next node in the file is the
> one with starting pos 32768, no matter if its version number is less than
> the logically previous node. If there are two of them, the one with the
> highest version is the right one, and so on.
I did a bit of testing today and I've had results I wasn't really
expecting. I created a JFFS filesystem with mkfs.jffs. It contained
/Configure.help which is 246941 bytes in size. (It was inode #2 at the
time and mkfs splitted it in 8 nodes). I then played with the file once
the filesystem was mounted. I did append, overwrite, copy a few time
(all to the same file).
The results ? Now Configure.help is inode #21, which is fine (it's now
splitted in 18 parts). I got 3 version of the node at offset 0
(versions 1, 2 and 19) all with the same mtime and all accurate.
Shouldn't the mtime from version 19 be higher ? Since there were no
power loss, shouldn't the accurate fields be set to 0? I also got the
node at offset 16365 twice, with the same version. I think this is
beacause this node was rewritten by the GC so this is ok but in that
case, shouldn't the accurate field from the old version be equal to 0?
I was wondering if I got these results because I forgot a few things in
my JFFS port, or maybe there's another explanation?