On 13/06/14 04:37, Liu Bo wrote:
The output of 'btrfs filesystem df' is appreciate, it can help determine if
the
FS has entered into 'almost full' situation, and that may cause a bug that
pages
are not marked with writeback tag and lead to processes's endless waiting.
I'll send it as soon
On 13/06/14 04:37, Liu Bo wrote:
The output of 'btrfs filesystem df' is appreciate, it can help determine if
the
FS has entered into 'almost full' situation, and that may cause a bug that
pages
are not marked with writeback tag and lead to processes's endless waiting.
The output now (when
Hi all,
I have a problem that triggers quite often on our production machines. I
don't really know what's triggering this or how to reproduce it, but the
machine enters in some sort of deadlock state, where it consumes all the
i/o and the load average goes very high in seconds (it even gets to
On 19/05/14 02:33, Chris Mason wrote:
I had this one in the integration branch, but lockdep reported troubles. It
looks like lockdep is correct. find_free_extent is nesting the cache rwsem
inside the groups rwsem, but btrfs_write_out_cache is holding the new cache
rwsem when it calls
Thanks for the response, Duncan.
On 01/05/14 17:58, Duncan wrote:
Tho you are slightly outdated on your btrfs-progs version, 3.14.1 being
current. But I think the code in question is kernel code and the progs
simply report it, so I don't think that can be the problem in this case.
Yes,
Hello,
I am having trouble with one of the btrfs subvolumes, as it shows
negative quota accounting values, like in the following output:
# btrfs qgroup show -f /tmp/test
qgroupid rfer excl
0/299-1576960 -1511424
Running
Hi all!
I am trying to create a very simple script that would alert in case of
disk failures from a RAID Btrfs.
Digging into the code, I have noticed that the btrfs fi sh command
should display a warning if there is a missing disk. However, testing in
a Qemu, I used drive_del via QMP to remove a
It seems that the problem was that we didn't delete the corresponding
qgroup when deleting the subvolume, which was filling the metadata with
unused information. Removing all the stale qgroups fixes the problem and
allows subsequent subvolume creation without any quota disable/enable
action.
Hello,
We are using btrfs filesystems in our infrastructure and, at some point
of time, they start refusing to create new subvolumes.
Each file system is being quota initialized immediately after its
creation (with btrfs quota enable) and then all subfolders under the
root directory are