On Sun, 2015-11-08 at 20:39 +0000, Duncan wrote: > Wow, yes! Good catch, Henk! =:^) Hugo obviously didn't catch it, > and I > wouldn't have either, as the bad size detection behavior is so > unexpected, it just wouldn't occur to me to look! Hmm... all that *may* be more likely an error of myself when copying and pasting the terminal output together: I did actually change the 3rd partition to use 1GiB in later tries at the expense of the 5th one shrinking, so the part table would have looked like this in these later tries: 512M 1G 1G 1G 4G Which would again fit the output of the various mkfs.btrfs. Sorry if that was the case, apologies for any confusion. The problem seemed to went away when explicitly using --mixed. > (Apparently, btrfs-progs-4.3 does away with the default to mixed- > mode at 1 GiB or under, tho it is still recommended. Well I still had 4.2 ... > I'm not exactly sure of > why, tho I think it had to do with being able to use sub-GiB btrfs > for > testing without having to worry about mixed mode. Kinda strange... shouldn't it work out of the box for users and not developers? To be honest, no one should need to read through the wiki, just to be able to create a small sized fs. And even if no mixed D/M block group allocation was used... it shouldn't just fail out-of-the-box with a few byte large files on a 1 GB fs. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
