Re: RAID1 disk upgrade method

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-01-28 18:01, Chris Murphy wrote:
> On Thu, Jan 28, 2016 at 1:44 PM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>>> Interesting, I figured a umount should include telling the drive to
>>> flush the write cache; but maybe not, if the drive or connection (i.e.
>>> USB enclosure) doesn't support FUA?
>>
>> It's supposed to send an FUA, but depending on the hardware, this may either
>> disappear on the way to the disk, or more likely just be a no-op.  A lot of
>> cheap older HDD's just ignore it, and I've seen a lot of USB enclosures that
>> just eat the command and don't pass anything to the disk, so sometimes you
>> have to get creative to actually flush the cache.  It's worth noting that
>> most such disks are not safe to use BTRFS on anyway though, because FUA is
>> part of what's used to force write barriers.
>
> Err. Really?
>
> [    0.833452] scsi 0:0:0:0: Direct-Access     ATA      Samsung SSD
> 840  DB6Q PQ: 0 ANSI: 5
> [    0.835810] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
> filtered out
> [    0.835827] ata3.00: configured for UDMA/100
> [    0.838010] usb 1-1: new high-speed USB device number 2 using ehci-pci
> [    0.839785] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [    0.839810] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks:
> (250 GB/233 GiB)
> [    0.840381] sd 0:0:0:0: [sda] Write Protect is off
> [    0.840393] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [    0.840634] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
>
> This is not a cheap or old HDD. It's not in an enclosure. I get the
> same message for a new Toshiba 1TiB drive I just stuck in a new Intel
> NUC. So now what?
Well, depending on how the kernel talks to the device, there are ways 
around this, but most of them are slow (like waiting for the write cache 
to drain).  Just like SCT ERC, most drives marketed for 'desktop' usage 
don't actually support FUA, but they report this fact correctly, so the 
kernel can often work around it.  Most of the older drives that have 
issues actually report that they support it, but just treat it like a 
no-op.  Last I checked, Seagate's 'NAS' drives and whatever they've 
re-branded their other enterprise line as, as well as WD's 'Red' drives 
support both SCT ERC and FUA, but I don't know about any other brands 
(most of the Hitachi, Toshiba, and Samsung drives I've seen do not 
support FUA).  This is in-fact part of the reason I'm saving up to get 
good NAS rated drives for my home server, because those almost always 
support both SCT ERC and FUA.

That said, you may want to test the performance difference with the 
write cache disabled, depending on how the kernel is trying to emulate 
write barriers, it may actually speed things up.
>
>
>>> If I don't, my drives make a loud clank, and the smart attribute 192
>>> Power-off Retract Count, goes up by one. This never happens on a
>>> normal power off. So some message is being sent to the drive at
>>> restart/poweroff that's different than just pulling the drive, even if
>>> that message isn't the same thing as whatever hdparm -Y sends.
>>>
>> I'm not saying it's a good idea to not tell the drive to spin down, just
>> that it won't damage most modern drives as long as they're kept level while
>> they spin down and you don't do it all the time.
>
> Gotcha.
>
>
>>
>> Almost every modern hard disk uses a voice-coil actuator for the heads which
>> gets balanced such that having no power to the coil causes the forces from
>> the spinning disks to park the heads, so pulling power will (more than 99.9%
>> of the time) not cause a head cash like a lot of older servo based drives as
>> long as you keep the drive level.  The clank you hear is the end of the head
>> armature opposite the heads hitting the mechanical stop that's present to
>> prevent them from completely decoupling from the disk.  This gets accounted
>> in SMART attributes because over extremely long times (usually tens
>> thousands of cycles), this will eventually wear out that mechanical stop,
>> and things will stop working, so it technically is a failure condition, but
>> you're almost certain to hit some other failure condition before this
>> becomes an issue.
>
> OK.
>
>>
>> The interesting thing is that some drives actually _rely_ on this behavior
>> to park the heads (I've seen a lot of Seagate desktop drives that appear to
>> do this, although they use a rubber stopper instead of metal or plastic, so
>> it tends to last longer).
>
> Cute.
>
Yeah, I've used a lot of Seagate drives that appear to do this, and 
they've always failed in some way other than this failing.  It is kind 
of nice though that it means you get clearly audible confirmation that 
the drive has spun down.