NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
aequus
Apr 26, 2015Aspirant
516 /dev/md127 suddenly read only- although space available
All my shares became suddenly read only although there is still 4TB free . After a reboot it was writeable for an hour but now it is again RO. OS version is latest 6.2.3 balance is done weekly. Wh...
aequus
May 07, 2015Aspirant
My 516 is not usable since two weeks now. I googled a little bit and found a known problems in a btfrs mailing list it sound very simular to my situation.
Can anyboby of the admin team help to get my 516 working again soon?
root@nas2:~# btrfs --version used by OS6
Btrfs v3.17.1
https://forums.opensuse.org/showthread. ... o-readonly
http://www.spinics.net/lists/linux-btrfs/msg38372.html
Juan Orti Alcaine posted on Wed, 15 Oct 2014 09:08:14 +0200 as excerpted:
> I've also experienced Btrfs corruptions with 3.17.0
> I do readonly snapshots every hour of all the subvolumes, so I have
> hundreds of snapshots.
That's a known issue with read-only snapshots in 3.17.0. There's quite a
thread on the list about it.
So I'd suggest either turning off read-only snapshots on 3.17 (which I'm
running here without snapshots, no problem), possibly switching to
writable snapshots as they don't seem to trigger the problem, or as you
mentioned doing already, going back to 3.16.x (x>2 due to another bug,
latest should be good), until the read-only snapshots issue with 3.17.0
is traced down and fixed.
Given the approximately two kernel cycles it took for the widely
reproduced but rather difficult to trace compression-related bug in 3.15
to be reported in 3.15 and traced and fixed in 3.17-rc2 and 3.16.2, I'd
guess a fix for this similarly widely reproduced read-only-snapshot-
related bug should be no later than 3.19-rc3 and 3.18.3, possibly rather
earlier if it proves easier to trace, especially since this one seems to
have been reported and recognized as widely occurring a bit faster than
the compression-related bug. But with testing, etc, it's still likely to
be late in the 3.18-rc cycle before mainline commit, so it'll probably be
rather late in the 3.17.x stable cycle, if it makes it at all. Unless it
gets picked as a long-term support kernel, the full 3.17 stable cycle
might in fact be blacklisted for btrfs due to this bug, much like the
full 3.15 stable cycle ended up being blacklisted due to the compression-
related bug.
So either switch your snapshots to writable if it's not going to
interfere with your use-case, or stay on the 3.16.x, x>2, stable series
until the problem is fixed, hopefully with 3.18.0, tho it might be 3.18.2
or so. I seriously doubt it'll be longer than that, because it's a well
reproduced bug which makes it both high priority and easy to test fixes
for.
Can anyboby of the admin team help to get my 516 working again soon?
root@nas2:~# btrfs --version used by OS6
Btrfs v3.17.1
https://forums.opensuse.org/showthread. ... o-readonly
http://www.spinics.net/lists/linux-btrfs/msg38372.html
Juan Orti Alcaine posted on Wed, 15 Oct 2014 09:08:14 +0200 as excerpted:
> I've also experienced Btrfs corruptions with 3.17.0
> I do readonly snapshots every hour of all the subvolumes, so I have
> hundreds of snapshots.
That's a known issue with read-only snapshots in 3.17.0. There's quite a
thread on the list about it.
So I'd suggest either turning off read-only snapshots on 3.17 (which I'm
running here without snapshots, no problem), possibly switching to
writable snapshots as they don't seem to trigger the problem, or as you
mentioned doing already, going back to 3.16.x (x>2 due to another bug,
latest should be good), until the read-only snapshots issue with 3.17.0
is traced down and fixed.
Given the approximately two kernel cycles it took for the widely
reproduced but rather difficult to trace compression-related bug in 3.15
to be reported in 3.15 and traced and fixed in 3.17-rc2 and 3.16.2, I'd
guess a fix for this similarly widely reproduced read-only-snapshot-
related bug should be no later than 3.19-rc3 and 3.18.3, possibly rather
earlier if it proves easier to trace, especially since this one seems to
have been reported and recognized as widely occurring a bit faster than
the compression-related bug. But with testing, etc, it's still likely to
be late in the 3.18-rc cycle before mainline commit, so it'll probably be
rather late in the 3.17.x stable cycle, if it makes it at all. Unless it
gets picked as a long-term support kernel, the full 3.17 stable cycle
might in fact be blacklisted for btrfs due to this bug, much like the
full 3.15 stable cycle ended up being blacklisted due to the compression-
related bug.
So either switch your snapshots to writable if it's not going to
interfere with your use-case, or stay on the 3.16.x, x>2, stable series
until the problem is fixed, hopefully with 3.18.0, tho it might be 3.18.2
or so. I seriously doubt it'll be longer than that, because it's a well
reproduced bug which makes it both high priority and easy to test fixes
for.
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!