Re: Corrupted system due to imbalanced metadata chunks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 17, 2016 at 9:45 AM, Peter Kese <peter.kese@xxxxxxxxxx> wrote:

> Then I tried a software upgrade (Ubuntu 15.10 -> 16.04) and it turned
> out that while there was more than 100 GB (45%) of free disk space,
> the upgrade process broke down somewhere in the middle reporting IO
> errors and lack of free disk space.

Kinda interesting, this appears in kernel 4.4.4

    btrfs: statfs: report zero available if metadata are exhausted
http://lkml.iu.edu/hypermail/linux/kernel/1603.0/01148.html

I think the OS upgrade case may still fail because there was probably
a lot of small files written inline in metadata chunks. So unless
there were a constant statfs check by the upgrader (like a per package
install check) then the first statfs check probably still overstates
the free space because it has no way of knowing there's about to be a
pile of small file writes.

And I've seen the reverse happen where it was metadata chunks with
free space, the data chunks were full and the enospc happened because
no data chunk could be allocated. So it's not so simple like adjusting
the data/metadata allocation ratio.

Huh. I wonder if after say, 90 or 95% full, Btrfs just switches to
creating a mixed-bg?

-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux