>> # reduce slack
>> root@zefir:~# btrfs fi resize 4:max /
>> Resize '/' of '4:max'
>> root@zefir:~# btrfs dev usage /
>> ...
>> /dev/sdb3, ID: 4
>> Device size: 1.80TiB
>> Device slack: 3.50KiB <<<<<<<<<<<<<<<<<<<<
>
> Maybe the partition isn't aligned on a 4KiB boundary? *shrug*
Yes... this is old partition table.
> But yeah one gotcha with 'btrfs replace' is that the replacement must
> be equal to or bigger than the drive being replaced; and once
> complete, the file system is not resized to fully utilize the
> replacement drive.
From my "user view" it is ok. After device replace was finished there
was slack = 1.7GiB.
Then I resised to max, and slack got down to 3.5KiB.
> That's intentional because by default you may want
> allocations to have the same balance as with the original device. If
> you resize to max, Btrfs will favor allocations to the drive with the
> most free space.
That's perfect.
>> Jan 5 13:52:09 zefir kernel: [1291932.446093] BTRFS warning (device
>> sdc1): i/o error at logical 11658111352832 on dev /dev/sde1, physical
>> 867246145536: metadata leaf (level 0) in tree 9109477097472
>
> Ahh yeah I see what you mean. I think that's confusing also. The error
> is on sde1. But I guess why sdc1 is reported first is probably to do
> with the device the kernel considers mounted, there's not really a
> good facility (or maybe it's in the newer VFS mount code, not sure)
> for showing two devices mounted on a single mount point.
Uhhh... you're right -- sdc1 is shown as mounted filesystem. Thank you.
I didn't see this detail at first, I thought information about sdc1
comes from BTRFS and not kernel mount.
root@zefir:~# mount | egrep sdc
/dev/sdc1 on / type btrfs
(rw,relatime,space_cache,subvolid=83043,subvol=/zefir)
root@zefir:~# cat /etc/fstab | egrep /
UUID=9d6e641c-ec71-411e-9312-f1f67a70913f / btrfs
defaults,subvol=/zefir 0 0
root@zefir:~# blkid | egrep 0913f
/dev/sdb3: UUID="9d6e641c-ec71-411e-9312-f1f67a70913f"
UUID_SUB="e9eb3d18-2d87-479a-808d-74d61903196c" TYPE="btrfs"
PARTUUID="c1befd42-e38c-be48-b8df-4301fa1d3b07"
/dev/sda1: UUID="9d6e641c-ec71-411e-9312-f1f67a70913f"
UUID_SUB="8bcae5cb-b3a5-4fd8-9284-602203f2a43e" TYPE="btrfs"
/dev/sdc1: UUID="9d6e641c-ec71-411e-9312-f1f67a70913f"
UUID_SUB="fb7055ef-6ae7-48e0-8f09-a315fc20f399" TYPE="btrfs"
/dev/sdf1: UUID="9d6e641c-ec71-411e-9312-f1f67a70913f"
UUID_SUB="5e38a881-9b21-4a35-a1bb-889095b32254" TYPE="btrfs"
/dev/sdd1: UUID="9d6e641c-ec71-411e-9312-f1f67a70913f"
UUID_SUB="1d776ab6-3ef2-4fe1-8026-78b6d87f85c1" TYPE="btrfs"
>> [/dev/sda1].write_io_errs 10418
>> [/dev/sda1].read_io_errs 227
>> [/dev/sda1].flush_io_errs 117
>> [/dev/sda1].corruption_errs 77
>> [/dev/sda1].generation_errs 47
>
> This isn't good either. I'd keep an eye on that. read errors can be
> fixed up if there's a good copy, Btrfs will use the good copy and
> overwrite the bad sector, *if* SCT ERC is lower duration than SCSI
> command timer. But write and flush errors are bad. You need to find
> out what that's about.
This was about wrong cable.
Cable was replaced. SCT ERC workarouds installed.
I would like to reset counters to ZERO... if it is possible (?).
