On 08/27/2015 12:52 AM, James Bottomley wrote:
> On Wed, 2015-08-26 at 08:40 +0200, Hannes Reinecke wrote:
>> On 08/26/2015 06:53 AM, Anatol Pomozov wrote:
>>> Hi
>>>
>>> On Sun, Aug 23, 2015 at 11:15 PM, Hannes Reinecke wrote:
> I looked at this commit and it actually adds SMR support to SCSI
On Wed, 2015-08-26 at 08:40 +0200, Hannes Reinecke wrote:
> On 08/26/2015 06:53 AM, Anatol Pomozov wrote:
> > Hi
> >
> > On Sun, Aug 23, 2015 at 11:15 PM, Hannes Reinecke wrote:
> >>> I looked at this commit and it actually adds SMR support to SCSI
> >>> layer. Reverting ATA_DEV_ZAC means going b
Hi
The same issue was reported here
http://www.spinics.net/lists/linux-ide/msg50641.html
Adding Adrian from Seagate to help track down this issue.
On Tue, Aug 25, 2015 at 11:40 PM, Hannes Reinecke wrote:
> On 08/26/2015 06:53 AM, Anatol Pomozov wrote:
>> Hi
>>
>> On Sun, Aug 23, 2015 at 11:15 P
On 08/26/2015 06:53 AM, Anatol Pomozov wrote:
> Hi
>
> On Sun, Aug 23, 2015 at 11:15 PM, Hannes Reinecke wrote:
>>> I looked at this commit and it actually adds SMR support to SCSI
>>> layer. Reverting ATA_DEV_ZAC means going back to zones-unaware
>>> algorithms. It is suboptimal but still much b
Hi
On Sun, Aug 23, 2015 at 11:15 PM, Hannes Reinecke wrote:
>> I looked at this commit and it actually adds SMR support to SCSI
>> layer. Reverting ATA_DEV_ZAC means going back to zones-unaware
>> algorithms. It is suboptimal but still much better than IO failures
>> and "BTRFS: lost page write d
Hi
On Sun, Aug 23, 2015 at 11:15 PM, Hannes Reinecke wrote:
> On 08/22/2015 07:23 PM, Anatol Pomozov wrote:
>> Hi
>>
>> On Fri, Aug 21, 2015 at 10:37 PM, Anatol Pomozov
>> wrote:
>>> Discs are from different batches and I was a bit surprised to see
>>> identical failures at the same time. I was
On 08/22/2015 07:23 PM, Anatol Pomozov wrote:
> Hi
>
> On Fri, Aug 21, 2015 at 10:37 PM, Anatol Pomozov
> wrote:
>> Discs are from different batches and I was a bit surprised to see
>> identical failures at the same time. I was ready send the drives to
>> RMA but then I discovered this thread
>>
On 08/22/2015 07:37 AM, Anatol Pomozov wrote:
> Hi
>
> I recently got 2 Seagate 8Tb drives. 'dd' over whole disc ran fine.
> Then I inserted into my RAID and started rebalancing. I've got
> following error almost immediately:
>
>
>
> ata5.00: failed command: WRITE FPDMA QUEUED
> ata5.00: cmd 61
Hi
On Fri, Aug 21, 2015 at 10:37 PM, Anatol Pomozov
wrote:
> Discs are from different batches and I was a bit surprised to see
> identical failures at the same time. I was ready send the drives to
> RMA but then I discovered this thread
> https://bbs.archlinux.org/viewtopic.php?id=199351 A lot of
Hello,
On Fri, Aug 21, 2015 at 10:37:44PM -0700, Anatol Pomozov wrote:
...
> https://bbs.archlinux.org/viewtopic.php?id=199351 A lot of people
> report the same problem as mine. It was found that the problem appears
> only starting from 3.19, with kernel 3.18 or Windows these drives work
> fine. I
Hi
I recently got 2 Seagate 8Tb drives. 'dd' over whole disc ran fine.
Then I inserted into my RAID and started rebalancing. I've got
following error almost immediately:
ata5.00: failed command: WRITE FPDMA QUEUED
ata5.00: cmd 61/00:e0:80:e7:75/1d:00:9f:00:00/40 tag 28 ncq 3801088 out
11 matches
Mail list logo
