On 17/05/14 08:08, William Kenworthy wrote:
> On 17/05/14 04:15, Marc Joliet wrote:
>> So, a week has passed since my conversion to btrfs.
>>
>...
>>
>> Have a nice weekend,
>>
>
> Don't forget to have a maintenance program - run a scrub regularly once
> a week or so - I have enough btrfs drives (22 qemu files, 4 WD Greens
> att) to see about one or two scrub fixable errors a week with no obvious
> cause, sometimes serious (in a critical file). My experience is that if
> you ignore these errors they seem to increase over time resulting in a
> crash and burn. Keep an eye on your logs as btrfs will list the errors
> there as well ("grep -i btrfs /var/log/messages"). For the ones scrub
> cant fix, delete the file and restore from backup. Errors that require
> off-line fixing (btrfsck) are the ones where I have lost file systems -
> though I have not seen this in the last 6 months.
>
> I am quite practised in restoring from backups because of btrfs :)
>
> BillK
>
>
>
This is from this mornings grep of the log:
May 15 07:00:34 myth kernel: btrfs: checksum error at logical 1775247360
on dev /dev/vda3, sector 5580816, root 5, inode 6423718, offset 1839104,
length 4096, links 1 (path:
var/log/mythtv/old/mythbackend.20140421061150.6275.log-20140515)
May 15 07:00:34 myth kernel: btrfs: bdev /dev/vda3 errs: wr 0, rd 0,
flush 0, corrupt 1, gen 0
May 15 07:00:34 myth kernel: btrfs: unable to fixup (regular) error at
logical 1775247360 on dev /dev/vda3
May 15 07:41:40 myth kernel: btrfs: bdev /dev/vda3 errs: wr 0, rd 0,
flush 0, corrupt 1, gen 0
and
May 16 20:40:33 moriah kernel: btrfs: bdev /dev/mapper/vg1-backups errs:
wr 0, rd 250, flush 0, corrupt 13, gen 0
sigh ....
BillK
