linux-kernel - RE: SATA hot unplug question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CABkmPjTQoJeQUHPce9-q2XYRorb5v6JzAMLYPM_OHVaYygB3aA@mail.gmail.com>
Date:	Fri, 22 Apr 2016 21:43:10 -0400
From:	Soohoon Lee <soohoon@...il.com>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Tejun Heo <tj@...nel.org>
Subject: RE: SATA hot unplug question

Forwarding to mailing list.
I think this is useful info so I like to share.

-----Original Message-----
From: Tejun Heo [mailto:htejun@...il.com] On Behalf Of Tejun Heo
Sent: Friday, April 22, 2016 1:29 PM
To: mkp@....net; Soohoon Lee
Cc: Ben Hutchings; Arnd Bergmann
Subject: Re: SATA hot unplug question



(Adding Martin, hey!)

On Fri, Apr 22, 2016 at 01:10:59PM -0400, Tejun Heo wrote:

> Hello,

>

> On Fri, Apr 22, 2016 at 02:59:25AM +0000, Soohoon Lee wrote:

> > We are having problem with SATA hot/surprise unplug, Linux treats

> > hot unplug as an IO error, so it keeps old drive info and drops link

> > speed when a new drive is plugged in.

> >

> > When I look at the code it looks like proper way to unplug is using 'delete'.

> >

> > echo 1 > /sys/block/sda/device/delete

> >

> > Is it right?

> > Or it's a hardware problem?

>

> So, PHYRdyChg and DevExch can be asserted from both temporary link

> issues and hotplug events and the driver can't declare the device

> "gone" immediately on those events.  What libata EH does is

> revalidating the device afterwards.  If it's still the same device,

> it's assumed to have suffered temporary link problems.  Otherwise, the

> current device gets detached and the new one gets probed.

>

> It becomes problematic when you hot unplug and replug the same drive

> soon - because the hdd lost power inbetween and the driver has no way

> of distinguishing that from a temporary link issues.  If the drive's

> writeback cache contained unwritten data, what the OS thinks that the

> drive has will be different from the reality which can lead to massive

> filesystem corruption.  So, it isn't a good idea to do that.

>

> Some setups have physical hotplug switches which can reliably detect

> drive being removed.  We never implemented it tho partly because it

> wasn't widely available and partly because it wasn't that useful given

> that the link events achieve most of what's actually useful.  That

> said, it'd be awesome if drives had power loss count so that

> revalidation can actually determine whether the drive lost power and

> then reject it.



Martin, the above is an idea I've had for a while - a power or
data-loss event count which is reliable and easily accessible and thus
can be used to tell whether a drive can be re-attached after a link
event.  SMART Power Cycle or Power-off Retract Count *may* be useable
for this purpose but I'm not sure whether depending on SMART counts is
a good idea.



It also would help with situations where faulty PSUs fail to maintain
voltage inducing a brief power (and data) loss event.  I haven't heard
of that lately so probably the situation is better now but I recall
several reports.  e.g. There was an entire server SKU which failed to
maintain voltage on hdd hotplug.  You put in one hdd and all others
briefly lose power leading to massive corruption.



Maybe it's too late to matter but maybe it could be discussed at one
of the standard meetings?



Thanks!



--

tejun