| |||||||||||||
A NILFS2 score cardA NILFS2 score cardPosted Nov 7, 2012 10:57 UTC (Wed) by etienne (subscriber, #25256)Parent article: A NILFS2 score card
IHMO there is another feature that FLASH system would need, it is the 0xFF hole:
When you create a hole in a file (by setting the current file pointer after the file's end and begin to write there), you get a hole that is full of 0x00 if read on standard Unix. It may be a good idea to get (the concept of) a hole full of 0xFF so the physical device can accept rewriting (few not-page-aligned bytes in) that area. Alternatively all data of some/every file may be XORed with 0xFF. But I am not sure how a hole is treated in a log filesystem...
(Log in to post comments)
A NILFS2 score card Posted Nov 7, 2012 14:17 UTC (Wed) by mirabilos (subscriber, #84359) [Link]
Why 0xFF ?
A NILFS2 score card Posted Nov 7, 2012 14:34 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Because the post-erasure state of a Flash cell signifies "all bits set", not "all bits clear".
A NILFS2 score card Posted Nov 7, 2012 14:43 UTC (Wed) by mirabilos (subscriber, #84359) [Link]
Ah, is that so? And for any and all Flash types?
I wonder why the hardware doesn’t flip that then…
In that case, storing data NOT’d might make sense,
A NILFS2 score card Posted Nov 7, 2012 16:47 UTC (Wed) by cmorgan (guest, #71980) [Link]
I'm not sure it matters what the erased state is as long as the "erased" value is defined and handled correctly.
Also keep in mind that some flash chips may not support flipping single bits inside of bytes or flipping individual bytes etc and warn against it. I've personally done this and it worked (and we had error correction) but for some reason the manufacturer said specifically not to. Maybe this is a serial flash only issue though. Can't say I've had that much experience with a range of flash parts.
A NILFS2 score card Posted Nov 8, 2012 16:30 UTC (Thu) by mirabilos (subscriber, #84359) [Link]
I was thinking of hardware engineers putting little NOT transistors on the D-bus of the flash chip, before attaching it to the system bus, so that a 0x00 on the system bus would be reas as 0xFF by the chip viceque versa. That would’ve been useful in this case.
But alas, if it isn’t… someone has to deal with it. (And the other comments suggest that the state may not be the same everywhere, so blindly XORing with FFh in the kernel will also not be a solution.)
A NILFS2 score card Posted Nov 9, 2012 18:09 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
This is true for NOR flash, which normally has a direct mapping of bits to cells and supports byte writes (or maybe even bit writes). It's not true for NAND flash, even if it's SLC: the individual cells are substantially less reliable so it requires ECC and block writes. A block that has been erased most likely won't have valid contents at all.
A NILFS2 score card Posted Nov 7, 2012 14:41 UTC (Wed) by hmh (subscriber, #3838) [Link]
Writing to a FLASH-like device means transitioning bits from 1 to 0 or leaving them unchanged. Erasing a FLASH-like device transitions all bits to 1.
So, a page full of 0xff is ready for writing. One full of 0x00 has to be erased to receive any other data. Only, you must erase a full block at a time, and blocks are (much) larger than pages.
A NILFS2 score card Posted Nov 7, 2012 18:46 UTC (Wed) by zlynx (subscriber, #2285) [Link]
But if the hardware has a FTL you have no real idea of how the actual hardware works. You only have the view through the FTL. Reading an erased block may return 0xFF. It may return 0x00. It might return the data that was in there before the "erase" operation. It might not read from the flash hardware at all because if the FTL has a range map of free/TRIM'd/secure-erased blocks it might check the range and return a purely synthetic block.
A NILFS2 score card Posted Nov 8, 2012 21:38 UTC (Thu) by Russ.Dill@gmail.com (subscriber, #52805) [Link]
While both NOR flash and NAND flash have this property, it isn't nearly as simple as you'd think.
For NAND flash, especially MLC NAND flash, each page is broken up into subpages that can be written individual, but must be written in order, and only a certain number of writes are allowed.
For both NAND and NOR, just because something looks like 0xFF doesn't mean its actually 0xFF, it could be an incomplete erase, and it may not read as 0xFF the next time.
Also, since we are talking log structured file systems, you don't allocate space for files anyway, you allocate space for writes. In the case of a file hole, you just don't allocate space.
The more I think about this, the less sense it makes, 0x00's don't appear in a file with a hole because 0x00's exist on the disk anyway...
A NILFS2 score card Posted Nov 9, 2012 9:51 UTC (Fri) by etienne (subscriber, #25256) [Link]
> since we are talking log structured file systems, you don't allocate space for files anyway, you allocate space for writes.
I have never gone into log structured file systems, I do not know how they handle the pattern people use to create contiguous files on standard filesystems (write a byte at beginning of the file, write a byte at the end of the file of known size, flush the file). Even the best filesystems cannot guess the final size of the file without hint, and even with delayed allocation at some point something has to be written to the disk.
> In the case of a file hole, you just don't allocate space.
But holes can appear at a random position, and usually the filesystem will not allocate blocks in a file hole on the parts aligned to sector sizes, so the filesystem has to write the default value on parts which are not aligned.
|
|||||||||||||