Re: recovery problem raid5

2016-05-03 Thread Pierre-Matthieu anglade
On Sat, Apr 30, 2016 at 1:25 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Pierre-Matthieu anglade posted on Fri, 29 Apr 2016 11:24:12 + as > excerpted: > So while btrfs in general, being still not yet fully stable, isn't yet > really recommended unless you're using data you can afford to lose,

Re: recovery problem raid5

2016-04-29 Thread Duncan
Pierre-Matthieu anglade posted on Fri, 29 Apr 2016 11:24:12 + as excerpted: > Setting up and then testing a system I've stumbled upon something that > looks exactly similar to the behaviour depicted by Marcin Solecki here > https://www.spinics.net/lists/linux-btrfs/msg53119.html. > > Maybe

recovery problem raid5

2016-04-29 Thread Pierre-Matthieu anglade
Hello all, Setting up and then testing a system I've stumbled upon something that looks exactly similar to the behaviour depicted by Marcin Solecki here https://www.spinics.net/lists/linux-btrfs/msg53119.html. Maybe unlike Martin I still have all my disk working nicely. So the Raid array is OK,

recovery problem raid5

2016-03-19 Thread Marcin Solecki
Hello all, I give up for this problem at restore my data # uname -a Linux jarvis.home 4.5.0-1.el7.elrepo.x86_64 # btrfs --version btrfs-progs v3.19.1 # btrfs fi show warning, device 4 is missing bytenr mismatch, want=21020672, have=21217280 Couldn't read chunk root Label: none uuid:

Re: recovery problem raid5

2016-03-19 Thread Chris Murphy
On Fri, Mar 18, 2016 at 5:31 PM, Chris Murphy wrote: > On Fri, Mar 18, 2016 at 12:02 PM, Hugo Mills wrote: >>The main thing you haven't tried here is mount -o degraded, which >> is the thing to do if you have a missing device in your array. >> >>

Re: recovery problem raid5

2016-03-19 Thread Duncan
Hugo Mills posted on Fri, 18 Mar 2016 18:02:07 + as excerpted: > Also, that kernel's not really all that good for a parity RAID > array -- it's the very first one that had the scrub and replace > implementation, so it's rather less stable with parity RAID than the > later 4.x kernels. That's

Re: recovery problem raid5

2016-03-19 Thread Marcin Solecki
W dniu 2016-03-19 o 00:40, Chris Murphy pisze: On Fri, Mar 18, 2016 at 5:31 PM, Chris Murphy wrote: On Fri, Mar 18, 2016 at 12:02 PM, Hugo Mills wrote: The main thing you haven't tried here is mount -o degraded, which is the thing to do if

Re: recovery problem raid5

2016-03-18 Thread Marcin Solecki
I try mount with -o degraded but this same effect what recovery: [ 7133.926778] BTRFS info (device sdc): allowing degraded mounts [ 7133.926783] BTRFS info (device sdc): disk space caching is enabled [ 7133.932140] BTRFS info (device sdc): bdev (null) errs: wr 921, rd 164889, flush 0, corrupt

Re: recovery problem raid5

2016-03-18 Thread Hugo Mills
The main thing you haven't tried here is mount -o degraded, which is the thing to do if you have a missing device in your array. Also, that kernel's not really all that good for a parity RAID array -- it's the very first one that had the scrub and replace implementation, so it's rather less

Re: recovery problem raid5

2016-03-18 Thread Chris Murphy
On Fri, Mar 18, 2016 at 12:02 PM, Hugo Mills wrote: >The main thing you haven't tried here is mount -o degraded, which > is the thing to do if you have a missing device in your array. > >Also, that kernel's not really all that good for a parity RAID > array -- it's the

Re: recovery problem raid5

2016-03-18 Thread Hugo Mills
On Fri, Mar 18, 2016 at 05:31:51PM -0600, Chris Murphy wrote: > On Fri, Mar 18, 2016 at 12:02 PM, Hugo Mills wrote: > >The main thing you haven't tried here is mount -o degraded, which > > is the thing to do if you have a missing device in your array. > > > >Also, that