After 1.5 days of running, the machine I was doing btrfs receive on got
stuck with this (note, the traces are not all the same).
The machine is not dead, but any IO that goes through btrfs seems dead.
If you want Sysrq-W, let me know.
Is thre anything I can try to unwedge or prevent this
Marc MERLIN posted on Thu, 20 Mar 2014 22:57:33 -0700 as excerpted:
On Sun, Mar 16, 2014 at 10:42:24PM -0700, Marc MERLIN wrote:
On Thu, Mar 06, 2014 at 09:33:24PM +, Duncan wrote:
However, best snapshot management practice does progressive snapshot
thinning, so you never have more than
Le 2014-03-19 06:57, Adam Khan a écrit :
Hello,
I have a simple btrfs located on a dm-crypt volume. I'm getting a
general protection fault when I
attempt to access a specific directory in Thunar file manager and in a
Python program.
The trace is attached for Thunar.
[ 313.491347]
If we have directories with a pending move/rename operation, we must take into
account any orphan directories that got created before executing the pending
move/rename. Those orphan directories are directories with an inode number
higher
then the current send progress and that don't exist in the
Regardless of whether the caller is interested or not in knowing the inode's
generation (dir_gen != NULL), get_first_ref always does a btree lookup to get
the inode item. Avoid this useless lookup if dir_gen parameter is NULL (which
is in some cases).
Signed-off-by: Filipe David Borba Manana
Regression test for a btrfs incremental send issue where the kernel failed
to build paths strings. This resulted either in sending a wrong path string
to the send stream or entering an infinite loop when building it.
This happened in the following scenarios:
1) A directory was made a child of
On Wed, Jan 08, 2014 at 12:02:06AM -0800, Marc MERLIN wrote:
On Tue, Jan 07, 2014 at 10:53:29AM +, Hugo Mills wrote:
You need to move /mnt/btrfs_pool2/tmp_read_only_new to a different
name as well. The send stream contains the name of the subvolume it
wants to create, so it's trying
On 03/21/2014 02:06 AM, Marc MERLIN wrote:
After 1.5 days of running, the machine I was doing btrfs receive on got
stuck with this (note, the traces are not all the same).
The machine is not dead, but any IO that goes through btrfs seems dead.
If you want Sysrq-W, let me know.
Is thre
Using openSUSE 13.1 on x86_64 which - as of this writing - is 3.11.10,
I tried to copy a bunch of files over to a btrfs filesystem (which was
mounted as /, in fact).
After some time, things ground to a halt and I got out of disk space errors.
btrfs fi df / showed about 1TB of *data* free, and
On Fri, Mar 21, 2014 at 02:24:45PM -0400, Josef Bacik wrote:
Is thre anything I can try to unwedge or prevent this problem next time I
try?
Sysrq+w would be nice so I can see what everybody is doing. Thanks,
Sure thing. There you go
http://marc.merlins.org/tmp/sysreq-w-btrfs.txt
(too big
10 matches
Mail list logo
