Summarizing what I've seen on the threads...
First of all many thanks for summarizing the info.
1) The bug seems to be read-only snapshot related. The connection to
send is that send creates read-only snapshots, but people creating
read-
only snapshots for other purposes are now reporting
...@prnet.org wrote:
From my own experience and based on what other people are saying, I
think there is a random btrfs filesystem corruption problem in kernel
3.17 at least related to snapshots, therefore I decided to post using
another subject to draw attention from people not concerned about btrfs
send
admin posted on Tue, 14 Oct 2014 13:17:41 +0200 as excerpted:
And if you're affected, be aware that until we have a fix, we don't
know if it'll be possible to remove the affected and currently
undeletable snapshots. If it's not, at some point you'll need to do a
fresh mkfs.btrfs, to get rid
On 10/14/2014 02:35 PM, Duncan wrote:
But at some point, presumably after a fix is in place, since the damaged
snapshots aren't currently always deletable, if the fix only prevents new
damage from occurring and doesn't provide a way to fix the damaged ones,
then mkfs would be the only way to do
Robert White posted on Tue, 14 Oct 2014 15:03:21 -0700 as excerpted:
What happens if btrfs property set is used to (attempt to) promote the
snapshot from read-only to read-write? Can the damaged snapshot then be
subjected to scrub of btrfsck?
e.g.
btrfs property set /path/to/snapshot ro
From my own experience and based on what other people are saying, I
think there is a random btrfs filesystem corruption problem in kernel
3.17 at least related to snapshots, therefore I decided to post using
another subject to draw attention from people not concerned about btrfs
send to it. More
On Mon, Oct 13, 2014 at 4:27 PM, David Arendt ad...@prnet.org wrote:
From my own experience and based on what other people are saying, I
think there is a random btrfs filesystem corruption problem in kernel
3.17 at least related to snapshots, therefore I decided to post using
another subject
I think I just found a consistent simple way to trigger the problem
(at least on my system). And, as I guessed before, it seems to be
related just to readonly snapshots:
1) I create a readonly snapshot
2) I do some changes on the source subvolume for the snapshot (I'm not
sure changes are
On Mon, Oct 13, 2014 at 4:48 PM, john terragon jterra...@gmail.com wrote:
I think I just found a consistent simple way to trigger the problem
(at least on my system). And, as I guessed before, it seems to be
related just to readonly snapshots:
1) I create a readonly snapshot
2) I do some
On Mon, Oct 13, 2014 at 4:55 PM, Rich Freeman
r-bt...@thefreemanclan.net wrote:
On Mon, Oct 13, 2014 at 4:48 PM, john terragon jterra...@gmail.com wrote:
After the rebooting (or the remount) I consistently have the corruption
with the usual multitude of these in dmesg
parent transid verify
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 unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
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
David Arendt posted on Mon, 13 Oct 2014 23:25:23 +0200 as excerpted:
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
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...@prnet.org wrote:
From my own experience and based on what other people are saying, I
think there is a random btrfs filesystem corruption problem in kernel
3.17 at least
On Mon, Oct 13, 2014 at 5:22 PM, john terragon jterra...@gmail.com 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).
I was using lzo compression, and hence my comment about turning it
And another worrying thing I didn't notice before. Two snapshots have
dates that do not make sense. root-b3 and root-b4 have been created
Oct 14th (and btw root's modification time was also on Oct the 14th).
So why do they show Oct 10th? And root-prov has actually been created
on Oct 10 15:37, as
17 matches
Mail list logo
