-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/2014 3:29 AM, Goffredo Baroncelli wrote:
On 10/10/2014 12:53 PM, Bob Marley wrote:
If true, maybe the closest indication we'd get of btrfs
stablity is the default enabling of autorecovery.
No way! I wouldn't want a default like that.
On 2014-10-10 18:05, Eric Sandeen wrote:
On 10/10/14 2:35 PM, Austin S Hemmelgarn wrote:
On 2014-10-10 13:43, Bob Marley wrote:
On 10/10/2014 16:37, Chris Murphy wrote:
The fail safe behavior is to treat the known good tree root as
the default tree root, and bypass the bad tree root if it
On 2014-10-12 06:14, Martin Steigerwald wrote:
Am Freitag, 10. Oktober 2014, 10:37:44 schrieb Chris Murphy:
On Oct 10, 2014, at 6:53 AM, Bob Marley bobmar...@shiftmail.org wrote:
On 10/10/2014 03:58, Chris Murphy wrote:
* mount -o recovery
Enable autorecovery attempts if a bad tree
On Sun, Oct 12, 2014 at 6:14 AM, Martin Steigerwald mar...@lichtvoll.de wrote:
Am Freitag, 10. Oktober 2014, 10:37:44 schrieb Chris Murphy:
On Oct 10, 2014, at 6:53 AM, Bob Marley bobmar...@shiftmail.org wrote:
On 10/10/2014 03:58, Chris Murphy wrote:
* mount -o recovery
Enable
On 10/08/2014 03:11 PM, Eric Sandeen wrote:
I was looking at Marc's post:
Am Donnerstag, 9. Oktober 2014, 21:58:53 schrieben Sie:
* btrfs-zero-log
remove the log tree if log tree is corrupt
* btrfs rescue
Recover a damaged btrfs filesystem
chunk-recover
super-recover
How does this relate to btrfs check?
* btrfs check
Am Freitag, 10. Oktober 2014, 10:37:44 schrieb Chris Murphy:
On Oct 10, 2014, at 6:53 AM, Bob Marley bobmar...@shiftmail.org wrote:
On 10/10/2014 03:58, Chris Murphy wrote:
* mount -o recovery
Enable autorecovery attempts if a bad tree root is found at mount
time.
I'm confused
Am Mittwoch, 8. Oktober 2014, 14:11:51 schrieb Eric Sandeen:
I was looking at Marc's post:
http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-
and-Btrfs-Filesystem-Repair.html
and it feels like there isn't exactly a cohesive, overarching vision for
repair of a
Martin Steigerwald posted on Sun, 12 Oct 2014 12:14:01 +0200 as excerpted:
I always thought with a controller and device and driver combination
that honors fsync with BTRFS it would either be the new state of the
last known good state *anyway*. So where does the need to rollback arise
from?
On 10/10/2014 12:53 PM, Bob Marley wrote:
If true, maybe the closest indication we'd get of btrfs stablity is
the default enabling of autorecovery.
No way! I wouldn't want a default like that.
If you think at distributed transactions: suppose a sync was issued
on both sides of a
On 10/10/2014 03:58, Chris Murphy wrote:
* mount -o recovery
Enable autorecovery attempts if a bad tree root is found at mount
time.
I'm confused why it's not the default yet. Maybe it's continuing to evolve at a
pace that suggests something could sneak in that makes things worse?
On Fri, 10 Oct 2014 12:53:38 +0200
Bob Marley bobmar...@shiftmail.org wrote:
On 10/10/2014 03:58, Chris Murphy wrote:
* mount -o recovery
Enable autorecovery attempts if a bad tree root is found at mount
time.
I'm confused why it's not the default yet. Maybe it's continuing to
On 10/10/2014 12:59, Roman Mamedov wrote:
On Fri, 10 Oct 2014 12:53:38 +0200
Bob Marley bobmar...@shiftmail.org wrote:
On 10/10/2014 03:58, Chris Murphy wrote:
* mount -o recovery
Enable autorecovery attempts if a bad tree root is found at mount
time.
I'm confused why it's not the
On Oct 10, 2014, at 6:53 AM, Bob Marley bobmar...@shiftmail.org wrote:
On 10/10/2014 03:58, Chris Murphy wrote:
* mount -o recovery
Enable autorecovery attempts if a bad tree root is found at mount
time.
I'm confused why it's not the default yet. Maybe it's continuing to evolve
at
If -o recovery is necessary, then you're either running into a btrfs
bug, or your hardware is lying about when it has actually written
things to disk.
The first case isn't unheard of, although far less common than it used
to be, and it should continue to improve with time.
In the second case,
On 10/10/2014 16:37, Chris Murphy wrote:
The fail safe behavior is to treat the known good tree root as the default tree
root, and bypass the bad tree root if it cannot be repaired, so that the volume
can be mounted with default mount options (i.e. the ones in fstab). Otherwise
it's a
On 2014-10-10 19:43, Bob Marley wrote:
On 10/10/2014 16:37, Chris Murphy wrote:
The fail safe behavior is to treat the known good tree root as the
default tree root, and bypass the bad tree root if it cannot be
repaired, so that the volume can be mounted with default mount options
(i.e. the
On 2014-10-10 13:43, Bob Marley wrote:
On 10/10/2014 16:37, Chris Murphy wrote:
The fail safe behavior is to treat the known good tree root as the
default tree root, and bypass the bad tree root if it cannot be
repaired, so that the volume can be mounted with default mount options
(i.e. the
On 10/10/14 2:35 PM, Austin S Hemmelgarn wrote:
On 2014-10-10 13:43, Bob Marley wrote:
On 10/10/2014 16:37, Chris Murphy wrote:
The fail safe behavior is to treat the known good tree root as
the default tree root, and bypass the bad tree root if it cannot
be repaired, so that the volume can
On 2014-10-08 15:11, Eric Sandeen wrote:
I was looking at Marc's post:
http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html
and it feels like there isn't exactly a cohesive, overarching vision for
repair of a corrupted btrfs filesystem.
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read errors. While BTRFS
technically handles both transparently on reads, it only corrects thing
on disk when
On Thu, Oct 09, 2014 at 11:53:23AM +, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read errors. While BTRFS
technically handles both
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read errors. While BTRFS
technically handles both transparently on reads, it
On Thu, Oct 09, 2014 at 08:07:51AM -0400, Austin S Hemmelgarn wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read
On 2014-10-09 08:12, Hugo Mills wrote:
On Thu, Oct 09, 2014 at 08:07:51AM -0400, Austin S Hemmelgarn wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and
On Thu, 09 Oct 2014 08:07:51 -0400
Austin S Hemmelgarn ahferro...@gmail.com wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct
bit-rot and force remapping of
On Thu, 9 Oct 2014 12:55:50 +0100
Hugo Mills h...@carfax.org.uk wrote:
On Thu, Oct 09, 2014 at 11:53:23AM +, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct
bit-rot and force
On 2014-10-09 08:34, Duncan wrote:
On Thu, 09 Oct 2014 08:07:51 -0400
Austin S Hemmelgarn ahferro...@gmail.com wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 09:18:22 -0400 as
excerpted:
On 2014-10-09 08:34, Duncan wrote:
The only way a read-only
mount should be writable is if it's mounted (bind-mounted or
btrfs-subvolume-mounted) read-write elsewhere, and the write occurs to
that mount, not the
On 10/9/14 8:49 AM, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 09:18:22 -0400 as
excerpted:
On 2014-10-09 08:34, Duncan wrote:
The only way a read-only
mount should be writable is if it's mounted (bind-mounted or
btrfs-subvolume-mounted) read-write elsewhere, and the
On Oct 8, 2014, at 3:11 PM, Eric Sandeen sand...@redhat.com wrote:
I was looking at Marc's post:
http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html
and it feels like there isn't exactly a cohesive, overarching vision for
repair of
Chris Murphy posted on Thu, 09 Oct 2014 21:58:53 -0400 as excerpted:
I suspect it's unintended splintering, and is an artifact that will go
away. I'd rather the convoluted, fractured nature of repair go away
before the scary experimental warnings do.
Heh, agreed with everything[1], but too
I was looking at Marc's post:
http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html
and it feels like there isn't exactly a cohesive, overarching vision for
repair of a corrupted btrfs filesystem.
In other words - I'm an admin cruising
33 matches
Mail list logo
