Quote:
Originally Posted by knc1
But it **must** write to correct errors found.
It isn't magic.
|
What i meant is that it doesn't rewrite whole regions: it does occasional scattershot writes (though this will probably have to change at some point when it gains more support for SMR drives, because as with flash those have restrictions on how and where you can safely write).
Quote:
|
And the flash 'write' (which it can't do, but must fake) is not the same effect of a hard drive with a bad sector that just sets an alternate sector (internally, in its controller).
|
Why do you claim it can't write to flash? Of course it can, but the modify write is *implemented* as an erase-and-new-write-and-pointer-update.
Quote:
|
The fact that fsck does not work in erase block chunks, erase block boundary aligned, is why it must start over.
|
That's only true if it's fscking below the level of the flash translation layer, which is vanishingly unlikely. Fading memories tell me that this is ext3, not a flash filesystem, so there's a translation layer here, so fsck will be emitting writes just as if it were on spinning rust, and relying on the translation layers to remap these writes correspondingly. There is no support whatsoever in fsck for storage media where you do a write and it doesn't show up until you restart fsck (how would the translation layer even know fsck had terminated?!). If this isn't an ext*fs then my argument is nonsense because I'm talking about a completely different fsck program than is actually in use.
(However, I am presuming in the absence of the evidence here. I'm not even sure which filesystem's being rebuilt, hence my question. Presumably it's not the squashfs ones -- those are never modified, and it doesn't even *have* a pristine original copy of that if one *is* somehow messed up. So it must be the modifiable system partition, which is IIRC ext3, right?)