[Fwd: Power Down]
Quoted 11 lines · Bob Canup
It is obvious that a physical medium such as a disk is vulnerable to having a bad sector created by the process that I described. The proof is simple: pop out a diskette while you are writing to it and you stand a good chance of creating a sector in which the CRC and data are out of sync. When you attempt to read the sector you will get a bad CRC.
This occurs in a diskette because the writing process is a serial event; it is spread over time. So there is a window in which an interruption can create a bad sector.
Quoted 11 lines
Let us assume the the DOC writes all of the bytes in a page including the ECC code in parallel, let us also assume that you have an internal bit which marks a sector as good when that process has completed. There nevertheless is a time during the 'burn' of the bits where we are in an analog state of changing the bits. If power is lost at that time - some of the bits will not have changed to their proper state. Even if the page is not marked as good an attempt to read the page will result in an ECC and data which do not match and the result is a bad sector. The sector may be easily recovered by erasing it and starting over - but as long as there is an analog aspect to changing the states - the bits will not all change at the same instant and a window for corruption exists.
Ah! buy having a CRC on the *ENTIRE* sector gets around this problem. Unless ALL the bits are burned in, the CRC will not match on a read. As to what happens the next time power comes back on, I guess that one does not erase the "good" sector till the new one is completely written. This way, at least you have the last (old) data still available.
Quoted 3 lines
Vipin's original post said that he saw bad sectors about once in every 250 power down cycles. Oran is telling us that can't occur.
I mailed a detailed post about this one a few mails ago. Plese refer that.
Quoted 4 lines
Of course if my analysis is correct then you are safe to erase the bad sector - it was the last one being written; the file system would then be left in a state in which e2fsck could hopefully repair it.
Unfortunately, if the lower layer driver does not know WHAT goes in that sector (inodes, data, etc), it could end up erasing a sector with inodes in it. This is something that e2fsck will not be able to recover from (at least without potentially killing a bunch of files on the system).
Quoted 4 lines
Or am I off in left field with this?
To unsubscribe, send "unsubscribe mtd" to [email protected]
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 24 lines · Vipin Malik
Quoted 11 lines · Bob Canup
It is obvious that a physical medium such as a disk is vulnerable to having a bad sector created by the process that I described. The proof is simple: pop out a diskette while you are writing to it and you stand a good chance of creating a sector in which the CRC and data are out of sync. When you attempt to read the sector you will get a bad CRC.
This occurs in a diskette because the writing process is a serial event; it is spread over time. So there is a window in which an interruption can create a bad sector.
Quoted 11 lines
Let us assume the the DOC writes all of the bytes in a page including the ECC code in parallel, let us also assume that you have an internal bit which marks a sector as good when that process has completed. There nevertheless is a time during the 'burn' of the bits where we are in an analog state of changing the bits. If power is lost at that time - some of the bits will not have changed to their proper state. Even if the page is not marked as good an attempt to read the page will result in an ECC and data which do not match and the result is a bad sector. The sector may be easily recovered by erasing it and starting over - but as long as there is an analog aspect to changing the states - the bits will not all change at the same instant and a window for corruption exists.
Quoted 7 lines
Ah! buy having a CRC on the *ENTIRE* sector gets around this problem. Unless ALL the bits are burned in, the CRC will not match on a read. As to what happens the next time power comes back on, I guess that one does not erase the "good" sector till the new one is completely written. This way, at least you have the last (old) data still available.
Quoted 1 line
What I was trying to do was outline the cause of the bad sector - CRC error problem during power loss. Certainly a CRC on the entire sector reports the problem - that is why one uses CRC's. You can identify a bad sector - the question is what do you do about it?
You are worried about losing inodes and directories to bad sectors. Let me pose a question: suppose that the power failed just before the write to the inode or directory sector - that there was no bad sector created - that the data was just never written to the recording media - do you see any way to recover from that problem?
I can't see any difference between erasing a bad sector after the next power up and the case of a slightly earlier power failure where the data was never written in the first place; you wind up with an identical file system in both cases. If you can survive the case of the earlier power failure failing to record the sector then you can survive the case of the bad sector being erased.
The only difference that I see is that in the case of the bad sector you know something happened, in the case of the data never being recorded you don't.
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 2 lines · [email protected] said:
You can identify a bad sector - the question is what do you do about
it?
Use a journalling filesystem. Make sure that any sector that's being written is disposable - if it gets wiped, then you can just do without it. Only remove your old copy of the filesystem data thats in that sector when you have a 100% guarantee that your write has hit the media correctly.
--
dwmw2
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 12 lines · Bob Canup
Quoted 3 lines · Vipin Malik
Quoted 1 line · Bob Canup
I can't see any difference between erasing a bad sector after the next power up and the case of a slightly earlier power failure where the data was never written in the first place; you wind up with an identical file system in both cases. If you can survive the case of the earlier power failure failing to record the sector then you can survive the case of the bad sector being erased.
Quoted 5 lines
The only difference that I see is that in the case of the bad sector you know something happened, in the case of the data never being recorded you don't.
To unsubscribe, send "unsubscribe mtd" to [email protected]
On the way home last night it occurred to me that if you are doing a read-modify-write cycle that it does make a difference where the error occurs. In this case if the sector is never written the old data is still valid.
It seems to me the wear leveling necessary in a flash can be a benefit here; if I understand correctly we don't overwrite the physical pages - only when a page is 'committed' does the chip change its mapping so that it appears that the sector was overwritten.
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 20 lines · Bob Canup
Quoted 12 lines · Bob Canup
Quoted 3 lines · Vipin Malik
Quoted 1 line · Bob Canup
I can't see any difference between erasing a bad sector after the next power up and the case of a slightly earlier power failure where the data was never written in the first place; you wind up with an identical file system in both cases. If you can survive the case of the earlier power failure failing to record the sector then you can survive the case of the bad sector being erased.
Quoted 5 lines
The only difference that I see is that in the case of the bad sector you know something happened, in the case of the data never being recorded you don't.
To unsubscribe, send "unsubscribe mtd" to [email protected]
Quoted 8 lines
On the way home last night it occurred to me that if you are doing a read-modify-write cycle that it does make a difference where the error occurs. In this case if the sector is never written the old data is still valid.
It seems to me the wear leveling necessary in a flash can be a benefit here; if I understand correctly we don't overwrite the physical pages - only when a page is 'committed' does the chip change its mapping so that it appears that the sector was overwritten.
The typical algorithm for writing new blocks into a flash system emulating a disk device assumes that for each block you can store you have a logical sector number and status.
- find an empty block
- write your data into it
- update the old data block status to say the logical block is being moved
- update the new data block status to show where the logical block now is
- update the old data block status to invalidate the entry
- start a sector erase if you need to
To read a block you look for a entry that shows the new location. If you can't find one but did find one that was marked as being moved you fall back to that.
This gets complicated because you have to handle both sector erases and block writes not completing from power failures. Which probably means that you don't want to do anything to freshly erased sectors. I.e. a freshly erased sector is identified simply because it is in its default erased state. You can't dedicate sectors to any particular use (because you need to load balance).
Signature · 6 lines
Stuart Lynne <[email protected]> __O <http://www.thinlinux.org> _-\<,_ 604-461-7532 PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68 To unsubscribe, send "unsubscribe mtd" to [email protected]