Btrfs disk surface scan

fennectech · 2014-09-11 06:20:53

Okay good question here. How do i make btrfsck scan for or become aware of bad blocks in the disk?

Last edited by fennectech (2014-09-12 05:16:13)

x33a · 2014-09-11 10:37:49

Please use a more descriptive thread title.

nstgc · 2014-09-11 18:22:10

You really don't fsck a btrfs partition. Instead you should run # btrfs scrub start /path/to/mounted/partition (I run it with the switches -Bd). Is there a reason you need to run fsck?

fennectech · 2014-09-11 21:10:32

did not know of btrfs scrub will check it out

karol · 2014-09-11 22:00:12

Please edit your first post and change the thread title as x33a asked.
Please use punctuation marks and capital letters.

fennectech · 2014-09-11 22:07:27

scrub device /dev/sda1 (id 1) done
scrub started at Thu Sep 11 16:22:59 2014 and finished after 1593 seconds
total bytes scrubbed: 81.63GiB with 68 errors
error details: csum=68
corrected errors: 0, uncorrectable errors: 68, unverified errors: 0
ERROR: There are uncorrectable errors.
[fennectech@archos ~]$

it only scrubed like a third of the disk

davidm · 2014-09-11 22:54:42

What kind of setup do you have? single,raid1, etc? It looks like you probably are using single for data and so there is no copy to correct the errors. If you are using data=raid1 at least scrub would usually be able to correct errors.

In any event check the disk(s) with smartctl to see if they have SMART errors. And it goes without saying if the data is important back it up if you haven't already!

Last edited by davidm (2014-09-11 22:55:21)

fennectech · 2014-09-11 23:11:41

im using a single aging disk i want to patch it up and the machine is working fine i ran it twice and it stopped at the same point in on my 280 something gig partition smart has a few sectors that have been remapped but it hasent changed in weeks the machine also still works just fine

davidm · 2014-09-12 00:15:19

fennectech wrote:

im using a single aging disk i want to patch it up and the machine is working fine i ran it twice and it stopped at the same point in on my 280 something gig partition smart has a few sectors that have been remapped but it hasent changed in weeks the machine also still works just fine

If it is stopping early that is a very bad sign. You might look into a non-destructive test with 'badblocks'. Be careful to use the non-destructive options. Because of the way SMART works often an error might not be shown until the sector is read from or written to. 'badblocks' is great for this.

As for the data wherever those errors are it's probably gone. There is no way to get it back (without backups) more than likely because you weren't running raid1+. There are ways to find which files the errors are occurring in (see the btrfs wiki) and you could then cut out those files.

If you really insist on using that disk you would be well advised to backup, deal with any errors on the btrfs fs, run badblocks, check smart data, and then rebalance with meta=dup,data=dup. At least that way there would be two copies of your data on the disk (but this would cut usable space in half at least). But usually once sectors start going bad it gets worse exponentially with time.

Last edited by davidm (2014-09-12 00:17:22)

fennectech · 2014-09-12 03:11:43

okay how would i tell btrfs not to use the blocks any more

emeres · 2014-09-12 03:24:05

karol wrote:

Please edit your first post and change the thread title as x33a asked.
Please use punctuation marks and capital letters.

@fennectech How about you follow x33as, karols and my suggestion?

fennectech · 2014-09-12 05:19:05

Okay so the scrub ddied 1/3 of the way through.
[fennectech@archos ~]$ sudo btrfs scrub status /dev/sda1
[sudo] password for fennectech:
scrub status for 9d7de4cb-d0a6-4b63-af65-9e055197808d
scrub started at Thu Sep 11 17:28:22 2014 and finished after 1665 seconds
total bytes scrubbed: 81.63GiB with 68 errors
error details: csum=68
corrected errors: 0, uncorrectable errors: 68, unverified errors: 0

there is the output m running badblocks right now and i will add the output from it in a moment Does anyone know how to inform BTRFS of badblocks?

edit i just broke down and ran SpinRite and it seems to have fixed stuff but im not sure if that will patch up btrfs

Last edited by fennectech (2014-09-12 08:49:12)

fennectech · 2014-09-12 09:01:17

The program found eight bad sectors but im not sure if its repairing of them will carry over to the btrfs filesystem

teateawhy · 2014-09-12 11:15:18

https://wiki.archlinux.org/index.php/Fo … ow_to_Post
A sincere effort to use modest and proper language and grammar is a sign of respect toward the community that will certainly be appreciated and is quite likely to elicit positive responses.

nstgc · 2014-09-12 13:23:24

davidm wrote:

If you really insist on using that disk you would be well advised to backup, deal with any errors on the btrfs fs, run badblocks, check smart data, and then rebalance with meta=dup,data=dup. At least that way there would be two copies of your data on the disk (but this would cut usable space in half at least). But usually once sectors start going bad it gets worse exponentially with time.

Last I read the documentation for btrfs, data=dup isn't supported. It is for meta, but not data. I remember this because it was a feature that ZFS has that I felt was missing in btrfs.

What you can do if put two partitions on the same drive and then raid them together. it would kill your drive IOps most likely, but your data would be safer. Doesn't gaurd against a drive failure though. If your drive dies you're still out of luck, and it sounds like your drive isn't exactly in great condition.

Also, in general, since btrfs is still somewhat experimental, you should have all your data backed up anyway.

fennectech wrote:

Does anyone know how to inform BTRFS of badblocks?
edit i just broke down and ran SpinRite and it seems to have fixed stuff but im not sure if that will patch up btrfs

Scrubbing a single drive might inform btrfs of an issue, but I don't know. It certainly seems like a reasonable design idea, if not a practical one (bad crc doesn't necessitate that a block is bad).

You say that SpinRite fixed it? Can you give any more information on how you can tell?

emeres · 2014-09-12 13:43:27

@fennectech If you have the possibility to backup data, do it. I would low level format the disk preferably using its manufacturer tool[⁣s], should there be any that is. If after that, you still have issues with the drive, consider looking for a replacement.

fennectech · 2014-09-12 23:18:28

Data safety isnt a point here. I am continualy backing up with dropbox the only thing that would be lost is the disk also i dont know where to get manufacturers tools and i havent seen low level formatting for a VERRY long time (not since the days or RLL and PLL) the drive WILL die and i know this im taking precautions to protect against data loss but i just need to make this drive last as long as possable.
Money is a huge issue here and i wont have more than ten bucks for another six months lol so i gotta keep going with this thing.

emeres · 2014-09-12 23:21:39

And since you do not provide any information on the manufacturer or the model, nobody will be able to help you. If you want to continue using it, format on low level.

fennectech · 2014-09-13 03:23:17

/dev/sda:

Model=TOSHIBA MK3263GSX, FwRev=FG020M, SerialNo=51MWTIPGT

Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=625142448
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7

* signifies the current active mode

fennectech · 2014-09-18 19:02:57

I am going to bump this post now

fennectech · 2014-10-15 01:59:57

I have been using the disk still cannot afford to replace it and i really do not to reload my OS that would be a royal pain in the arse sometimes the disk goes read only but it doesnt correct for the problem

fennectech · 2014-10-17 10:53:20

okay so i can generate a badblocks file thats not the problem how do i inform the filesystem that the blocks in the file are not to be used!

davidm · 2014-10-19 00:25:57

fennectech,

Sorry to tell you but it seems that there is no bad block marking as described in btrfs. At least that is what this btrfs mailing list message suggests:

There's no marking of bad blocks right now, and I don't know of
anyone working on the feature, so the FS will probably keep going back
to the bad blocks as it makes CoW copies for modification.

http://comments.gmane.org/gmane.comp.fi … trfs/31525

If you really MUST use that disk (and I've been there too) then you might want to switch over to ext4 or such then where I believe the bad block mapping is supported.

Good luck.

PS- Maybe you could at least keep a live CD/usb to use so that you can boot from that if your install totally crashes. Then you could write any important data to another USB flash device assuming you have one to hold you over until you get the necessary funds to replace the drive.

Last edited by davidm (2014-10-19 00:28:35)

fennectech · 2014-10-20 09:09:21

okay well the few times it has gone R/O a simple reboot has restored it quickly enough and theres no way i can use ext4 i NEED the fault tolerence that btrfs provides

frostschutz · 2014-10-20 17:54:00

If you know where the bad blocks are, you could partition the disk so the bad blocks (and generous close-by areas) are not covered by any partition.

The partitions themselves could then be merged into one big storage by LVM/btrfs/whatever.

But if the disk develops new bad blocks, that won't help you either. Unless you find a way to remove partitions on the go.

For example you could divide your disk into 1GB sized partitions and remove any partition that has a bad block in the future...

Just get a new disk already.

Last edited by frostschutz (2014-10-20 17:54:44)

Arch Linux

#1 2014-09-11 06:20:53

Btrfs disk surface scan

#2 2014-09-11 10:37:49

Re: Btrfs disk surface scan

#3 2014-09-11 18:22:10

Re: Btrfs disk surface scan

#4 2014-09-11 21:10:32

Re: Btrfs disk surface scan

#5 2014-09-11 22:00:12

Re: Btrfs disk surface scan

#6 2014-09-11 22:07:27

Re: Btrfs disk surface scan

#7 2014-09-11 22:54:42

Re: Btrfs disk surface scan

#8 2014-09-11 23:11:41

Re: Btrfs disk surface scan

#9 2014-09-12 00:15:19

Re: Btrfs disk surface scan

#10 2014-09-12 03:11:43

Re: Btrfs disk surface scan

#11 2014-09-12 03:24:05

Re: Btrfs disk surface scan

#12 2014-09-12 05:19:05

Re: Btrfs disk surface scan

#13 2014-09-12 09:01:17

Re: Btrfs disk surface scan

#14 2014-09-12 11:15:18

Re: Btrfs disk surface scan

#15 2014-09-12 13:23:24

Re: Btrfs disk surface scan

#16 2014-09-12 13:43:27

Re: Btrfs disk surface scan

#17 2014-09-12 23:18:28

Re: Btrfs disk surface scan

#18 2014-09-12 23:21:39

Re: Btrfs disk surface scan

#19 2014-09-13 03:23:17

Re: Btrfs disk surface scan

#20 2014-09-18 19:02:57

Re: Btrfs disk surface scan

#21 2014-10-15 01:59:57

Re: Btrfs disk surface scan

#22 2014-10-17 10:53:20

Re: Btrfs disk surface scan

#23 2014-10-19 00:25:57

Re: Btrfs disk surface scan

#24 2014-10-20 09:09:21

Re: Btrfs disk surface scan

#25 2014-10-20 17:54:00

Re: Btrfs disk surface scan

Board footer