I get a similar read-only status when I try to remove the drive from the array..
Too bad the utility's function can not be slowed down.. to avoid triggering this error... ? I had some success putting data *onto* the drive by croning sync every two seconds in a different terminal. Doesn't seem to be fixed yet.. https://bugzilla.kernel.org/show_bug.cgi?id=93581 On Sun, Nov 1, 2015 at 9:17 AM, Roman Mamedov <r...@romanrm.net> wrote: > On Sun, 1 Nov 2015 09:07:08 -0500 > Ken Long <kelargo1...@gmail.com> wrote: > >> Yes, the one drive is that Seagate 8TB drive.. >> >> Smart tools doesn't show anything outrageous or obvious in hardware. >> >> Is there any other info I can provide to isolate, troubleshoot further? >> >> I'm not sure how to correlate the dmesg message to a specific drive, >> SATA cable etc.. > > See this discussion: http://www.spinics.net/lists/linux-btrfs/msg48054.html > > My guess is these drives need to do a lot of housekeeping internally, > especially during heavy write load or random writes, and do not reply to the > host machine in time, which translates into those "frozen [...] failed > command: WRITE FPDMA QUEUED" failures. > > I did not follow the issue closely enough to know if there's a solution yet, > or > even if this is specific to Btrfs or to GNU/Linux in general. Maybe your best > bet would be to avoid using that drive in your Btrfs array altogether for the > time being. > > -- > With respect, > Roman -- 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
