Hi,
I received the message: btrfs: unlinked 34 orphans
Just out of couriosity: what does it mean ?
Thanks in advance
Bye,
David Arendt
--
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
Hi,
As I like experimenting with file systems, and as lots of boot cds don't
have the latest kernel/userspace tools, I decided to create my own
bootcd for my personal use. As I think it could be interesting for other
people, I made it available at http://prrescue.prnet.org
Bye,
David Arendt
at http://vger.kernel.org/majordomo-info.html
Hi,
I completely agree with you. I think lots of people use snapshots for
backup purposes and these ones shouldn't be writable.
Bye,
David Arendt
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
Hi,
thanks,
this patch fixes the problem
Bye,
David Arendt
On 11/15/12 05:21, Marios Titas wrote:
On Wed, Nov 14, 2012 at 5:34 PM, David Arendt ad...@prnet.org wrote:
Hi,
I am using kernel 3.7.0-rc5 and latest btrfs-progs git.
I am trying btrfs send/receive. When I have a filesystem
?
Thanks in advance,
David Arendt
--
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
Well, this is only code to demonstrate the problem, the ; is normally a
silly mistake, but for my test case valuelen is 0 so, the ; doesn't
change anything. With this corrected, the problem stays the same.
On 11/23/12 21:43, Garry T. Williams wrote:
On Friday, November 23, 2012 18:45:04 David
Hi,
There is no dmesg output.
Thanks in advance,
David Arendt
On 11/24/12 04:39, Liu Bo wrote:
On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
Well, this is only code to demonstrate the problem, the ; is normally a
silly mistake, but for my test case valuelen is 0 so
processing attribute user.testattribute
value testvalue
Thanks in advance,
David Arendt
On 11/24/12 04:39, Liu Bo wrote:
On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
Well, this is only code to demonstrate the problem, the ; is normally a
silly mistake, but for my test case
and will try to do a new install on a loop device to
figure out which userspace program creates files this way.
Thanks in advance,
David Arendt
On 11/27/12 08:46, Liu Bo wrote:
Hi,
(cc btrfs Mailing list to notify others.)
Thanks for the helpful test.img.
Well...after deeper debug, I'm sure
-a /mnt/test/test1 /mnt/test/test2
/root/x/testxattr /mnt/test/test2
processing file /mnt/test/test2
processing attribute system.posix_acl_default
lgetxattr failed: No data available
Might it be a bug in coreutils ?
Thanks in advance,
David Arendt
On 11/27/12 08:46, Liu Bo wrote:
Hi,
(cc
Hi,
your patches seem to fix the problem
Thanks,
David Arendt
On 11/28/12 11:54, Liu Bo wrote:
On Tue, Nov 27, 2012 at 08:20:54PM +0100, David Arendt wrote:
Hi,
I have now tested a gentoo reinstall with a recompile of nfs-utils. By
observing how the directory /var/lib/nfs is created, I
debugging this issue.
Thanks in advance,
David Arendt
--
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
wrote:
On Mon, Oct 6, 2014 at 2:50 PM, David Arendt ad...@prnet.org wrote:
Hi,
After upgrading to kernel 3.17 btrfs send has stopped working.
ERROR: send ioctl failed with -5: Input/output error
The following message is printed by kernel:
[75322.782197] BTRFS error (device sda2): did not find
I just tried downgrading to 3.16.3 again. In 3.16.3 btrfs send is
working without any problem. Afterwards I upgraded again to 3.17 and the
problem reappeared. So the problem seems to be kernel version related.
On 10/06/2014 09:06 PM, Chris Mason wrote:
On Mon, Oct 6, 2014 at 2:50 PM, David
On 10/07/2014 03:19 PM, Chris Mason wrote:
On Tue, Oct 7, 2014 at 1:25 AM, David Arendt ad...@prnet.org wrote:
I did a revert of this commit. After creating a snapshot, the
filesystem was no longer usable, even with kernel 3.16.3 (crashes 10
seconds after mount without error message) . Maybe
found 8325
On 10/07/2014 10:46 PM, Chris Mason wrote:
On Tue, Oct 7, 2014 at 4:45 PM, David Arendt ad...@prnet.org wrote:
On 10/07/2014 03:19 PM, Chris Mason wrote:
On Tue, Oct 7, 2014 at 1:25 AM, David Arendt ad...@prnet.org wrote:
I did a revert of this commit. After creating a snapshot
Just to let you know, I just tried an ls -l on 2 machines running kernel
3.17 and btrfs-progs 3.16.2.
Here is my ls -l output:
Machine 1:
ls: cannot access root.20141009.000503.backup: Cannot allocate memory
total 0
d? ? ? ? ?? root.20141009.000503.backup
. Maybe this is pure coincidence and has nothing to do with the
fact that it is on SSD or HDD. Another thing I noticed is that for me,
the problem only seems to occur for root subvolumes with many small
files. I have no root subvolumes on HDD so it might be not SSD related.
On 10/12/2014 11:35 PM, David
On 10/13/2014 02:40 PM, john terragon wrote:
Actually it seems strange that a send operation could corrupt the
source subvolume or fs. Why would the send modify the source subvolume
in any significant way? The only way I can find to reconcile your
observations with mine is that maybe the
information can be found in the brtfs send posts.
Did the filesystem you tried to balance contain snapshots ? Read only ones ?
On 10/13/2014 07:22 PM, Rich Freeman wrote:
On Sun, Oct 12, 2014 at 7:11 AM, David Arendt ad...@prnet.org wrote:
This weekend I finally had time to try btrfs send again
As these to machines are running as server for different purposes (yes,
I know that btrfs is unstable and any corruption or data loss is at my
own risk therefore I have good backups), I want to reboot them not more
then necessary.
However I tried to bring my reboot times in relation with
I'm also using no compression.
On 10/13/2014 11:22 PM, john terragon wrote:
I'm using compress=no so compression doesn't seem to be related, at
least in my case. Just read-only snapshots on 3.17 (although I haven't
tried 3.16).
John
--
To unsubscribe from this list: send the line
failed on 18317623296 wanted 275876
found 278431
[ 84.650557] parent transid verify failed on 127254528 wanted 276488
found 276490
On 10/14/14 12:36 AM, Duncan wrote:
Rich Freeman posted on Mon, 13 Oct 2014 16:42:14 -0400 as excerpted:
On Mon, Oct 13, 2014 at 4:27 PM, David Arendt ad
I didn't notice a corruption on other filesystems with kernel 3.17.0.
Also I didn't experience any hangs except when trying to mount a
corrupted btrfs but this was causing a hang within less than 10 seconds.
It could be that your problem is unrelated and that the corruption you
are
wrong here ?
Thanks in advance,
David Arendt
--
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
with -rc7 and -rc8. It seems only to occur when copying from
7200rpm harddisks to 5600rpm ones, and never when copying between two
7200rpm or two 5400rpm.
Thanks,
David Arendt
On 12/13/2016 08:55 PM, Xin Zhou wrote:
> Hi David,
>
> It has GFP_NOFS flags, according to definition,
> the
Hi,
Is it safe to interrupt a btrfs filesystem defrag -r / by using ctrl-c
or should it be avoided ?
Thanks in advance,
David Arendt
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
27 matches
Mail list logo
