lu...@plaintext.sk writes:
Hello,
> luvar@blackdawn:~$ sudo time btrfs balance start -dconvert=raid1 -dusage=20
> /home/luvar/programs/
> Am I doing something forbidden (I have not see any structure where
> raid type is stored per file/subvolume item), or I just hit some
> problem? What should I try?
btrfs doesn't yet support per-subvolume RAID1 levels. I'm not sure how
it should behave with your command line. It probably tries to
rebalance the whole filesystem.
> Than I wanted to convert to raid1 also some data (with balance
> filter) and try if there is some speedup when reading files
> (starting programs)...
Though I can already tell that no, there won't be a speedup, as btrfs
scheduler chooses the device to access by using the process id as a
seed. Therefore a single thread is never able to use 100% RAID1 input
capability. Perhaps in future there will be more sophisticated
schedulers. You may try to use MD raid1 for extra speed, but you would
lose the automatic error recovery of btrfs (but you would still notice
if data gets corrupted).
> [ 8159.300427] attempt to access beyond end of device
> [ 8159.300434] sdb2: rw=1041, want=480110048, limit=473956352
> [ 8159.300440] btrfs: bdev /dev/sdb2 errs: wr 638628, rd 65867, flush 0,
> corrupt 0, gen 0
I have noticed that 'attempt to access beyond end of device' typically
indicates (with other file systems, I haven't seen that with btrfs)
that the partition table and the filesystem size don't
match. Typically such a situation could occur when one modifies
partition table after creating the file system, though I'm sure there
are other ways to get into such a situation. You may find the
filesystem size with btrfs filesystem show and partition sizes with
cat /proc/partitions (multiply by block size = 1024 bytes).
Should the partition sizes and filesystem sizes match, I would be
quite certain this would indeed be a btrfs bug. But,
> root@blackdawn:/home/luvar# uname -a
> Linux blackdawn 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> root@blackdawn:/home/luvar# btrfs v
> Btrfs v0.20-rc1-189-g704a08c
should this turn out to be a bug, I'm certain trying a more recent
kernel version is a terrific idea :). 3.18.x or 3.17.y where y>2 (I
think those were the two versions that were bad in 3.17
series..). They won't have support for raid1'n a subvolume either,
though, as far as I know.
Remember backups :).
--
_____________________________________________________________________
/ __// /__ ____ __ http://www.modeemi.fi/~flux/\ \
/ /_ / // // /\ \/ / \ /
/_/ /_/ \___/ /_/\_\@modeemi.fi \/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
