bad blocks tolerant filesystem?

thetrivialstuff · 2012-02-10 22:07:07

Are there any filesystems that can robustly handle bad blocks, even when the underlying hardware is not reporting them? An example of this would be a hard drive or an SSD that returns "success" on every read, even if the data it returns is not what was written to that sector. (The Samsung P-SSD1800 solid-state drive present in my Acer AspireOne ZG5 netbook is one such device. Grr.)

Running "badblocks -w" is able to find these malfunctioning sectors because it doesn't rely on the device to return read errors, it just writes a value, then tells the device, "OK, read back what I just gave you" and if it's wrong, it's wrong. But the trouble is that the device seems to be trying its best to reallocate the bad blocks and doing a miserable job of it, because they move around. I suspect that there's actually no bad block reallocation at all, and that the malfunctioning flash cells are able to write successfully sometimes but not others (so badblocks will find them sometimes, sometimes not).

So, what I want is a filesystem that doesn't trust the underlying device at all, and read-verifies absolutely every write. And when it *doesn't* reread correctly, I want the filesystem to be smart enough to try again writing the data somewhere else until it works.

Am I dreaming? Should I just wait for the replacement SSD I ordered to get here (it's coming in 2 weeks)? :)

(It looks like ZFS could possibly do this, but I've read varying things implying that it relies on the underlying device to do the bad block remapping when it 'heals' a file. If that's the case, it probably won't work on my crappy SSD. I've also seen reports that ZFS is incredibly memory-hungry, which wouldn't be so good on a netbook...

Before this happened I was using NILFS2, which apparently does enough checksumming that it won't return silently corrupted files -- comparing against my backups after the crash, only good files were still readable. So yay NILFS, but I still want to get some use out of my netbook in the mean time.)

~Felix.

adee · 2012-02-11 15:06:27

Under Linux, probably the best workaround would be using Btrfs with it's built-in RAID capabilities. But that only works with at least two drives doing mirroring. Then Btrfs will silently re-copy the file from the other drive in case of a checksum error. But this is just an ugly workaround, you should replace that SSD ASAP.

thetrivialstuff · 2012-02-11 17:52:41

How useable is btrfs? The man pages still say it's "under heavy development, and not suitable for any uses other than benchmarking and review." But yeah, I don't have a secondary device to mirror to on here, so it wouldn't be all that different from NILFS.

Actually, it looks as if I messed up when I chose NILFS as my filesystem. I read a bunch of reviews of it that said it was good for SSD's, but I overlooked the fact that the superblocks are in a fixed location on the disk and are majorly write-amplified -- there's a log pointer that gets updated on *every single write to anywhere on the filesystem*, which of course causes those blocks to be rewritten again and again. Sure enough, most of the badness seems to be in the first and last blocks.

But that's also a good thing in a way, because A) the rest of the SSD was getting nicely wear-levelled by the way NILFS works and B) If I just shrink the partition by a block on either side, I can probably get a bit more life out of it. But yeah, I have a replacement SSD on order.

...Then again, there's also a patch of bad sectors in the middle of /home, so it's probably not all NILFS's fault. I think the previous owner of this netbook ran Windows XP and might've even had a pagefile enabled... he didn't use the netbook much (fortunately), but ugh.

In the mean time, my workaround is to put home on tmpfs in RAM and do this on shutdown:
tar -c home/ | gzip -1 | dd of=/dev/mapper/home bs=1M seek=48
and on boot:
dd if=/dev/mapper/home bs=1M skip=48 | gunzip | tar -x

...and to stay in sleep mode instead of shutting down, and save changed files off to somewhere else whenever I can, to avoid having to rewrite that tarball. Gzip has enough checksumming to be able to confirm that that location is good, and is clever enough to ignore data that comes after its EOF marker, so I don't need to know the exact size when I'm reading it back out. If I run into a bad sector, I can just change that seek=/skip= parameter to try again somewhere else, and as long as I remember where I put it, I'm fine.

I've been toying with the idea of writing my own filesystem based on the above (with a bunch of logic to save changed files to small incremental batches, written where the previous one left off so that it wear-levels the disk, and then sequentially reassembles them on read...) -- but I'm betting my replacement SSD will get here before I can waste too much time on that

~Felix.

graysky · 2012-02-11 18:00:27

https://bbs.archlinux.org/viewtopic.php?id=134643

Arch Linux

#1 2012-02-10 22:07:07

bad blocks tolerant filesystem?

#2 2012-02-11 15:06:27

Re: bad blocks tolerant filesystem?

#3 2012-02-11 17:52:41

Re: bad blocks tolerant filesystem?

#4 2012-02-11 18:00:27

Re: bad blocks tolerant filesystem?

Board footer