ignoring bad blocks

ignoring bad blocks

[Dyweni - BTRFS]

Hi All,

Can BTRFS ignore bad blocks as they are discovered?

I want to try BTRFS on some older drives, but they all have a few bad 
blocks.

Thanks,
Dyweni

Re: ignoring bad blocks

[Chris Murphy]

On Sat, Jan 3, 2015 at 10:40 PM, Dyweni - BTRFS <Y4BwxfPC4k5h@dyweni.com> wrote:
> Hi All,
>
> Can BTRFS ignore bad blocks as they are discovered?
>
> I want to try BTRFS on some older drives, but they all have a few bad
> blocks.

Not currently, and I don't see it in the project ideas list. Right now
on Btrfs you will just get write errors, but I'm uncertain if it just
tries a new sector and continues on (indirectly not use the bad sector
but also not keeping track of it either)? The unreliable disk features
are still project ideas.

If the drives no longer have reserve sectors, then technically they're
toast. That's indicated by write failure in dmesg. Two work arounds:
use ext4 with mkfs.ext4 -c which builds a bad blocks list and then
won't use those sectors; mdadm 3.1+ has an option to build a bad
blocks list also but I don't know if raid0 or linear/concat are
supported:
http://thread.gmane.org/gmane.linux.raid/34883

If you haven't tried it, badblocks -wvs will (destructively) write
over the entire block device, and the drive firmware should detect
persistent write failures automatically and remap the LBA to a reserve
sector, removing the bad sector from use. This is transparent to
everything outside the drive. Once reserve sectors are depleted then
the drive will report write failure.



-- 
Chris Murphy

Re: ignoring bad blocks

[Marc MERLIN]

On Sun, Jan 04, 2015 at 01:45:41AM -0700, Chris Murphy wrote:
> On Sat, Jan 3, 2015 at 10:40 PM, Dyweni - BTRFS <Y4BwxfPC4k5h@dyweni.com> wrote:
> > Hi All,
> >
> > Can BTRFS ignore bad blocks as they are discovered?
> >
> > I want to try BTRFS on some older drives, but they all have a few bad
> > blocks.
> 
> Not currently, and I don't see it in the project ideas list. Right now
> on Btrfs you will just get write errors, but I'm uncertain if it just
> tries a new sector and continues on (indirectly not use the bad sector
> but also not keeping track of it either)? The unreliable disk features
> are still project ideas.

badblocks are a thing of the past, as you hinted drives automatically
remap badblocks so that the filesystem doesn't have to deal with them.

If you have a questionable drive, you can indeed simply dd 0's over it
before you use it with btrfs.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: ignoring bad blocks

[Chris Murphy]

On Sun, Jan 4, 2015 at 8:18 AM, Marc MERLIN <marc@merlins.org> wrote:

> badblocks are a thing of the past, as you hinted drives automatically
> remap badblocks so that the filesystem doesn't have to deal with them.
>
> If you have a questionable drive, you can indeed simply dd 0's over it
> before you use it with btrfs.

I suggest badblocks because the default works on both 512 or 4096 byte
physical sector drives.

On AF 512e drives, dd default block size of 512 bytes will fail if a
bad sector is encountered. What happens (to at least one model of
drive since I've had this happen to me) is the 512 byte write to a bad
4096 byte sector gets interpreted by the drive as a Read Write Modify.
So do use dd you need to also use bs= setting it to a multiple of
4096. Of course most people using dd for zeroing set bs= to a decently
high value because it makes the process go much faster than the
default block size of 512 bytes.

I just used strace on badblocks and by default issues 64KiB writes
(the block size is 1024 bytes with a count of 64, which looks like it
gets aggregated).

-- 
Chris Murphy

Re: ignoring bad blocks

[Russell Coker]

On Sun, 4 Jan 2015 13:46:30 Chris Murphy wrote:
> So do use dd you need to also use bs= setting it to a multiple of
> 4096. Of course most people using dd for zeroing set bs= to a decently
> high value because it makes the process go much faster than the
> default block size of 512 bytes.

You could just use cat(1) to write to the disk.  Cat SHOULD write a minimum of 
page size buffers unless the kernel tells it that the device block size is 
larger.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/