Any objections/comments on axing out old ATA stack?

Thu Apr 4 08:00:24 UTC 2013

Am 04.04.2013 03:05, schrieb Jeremy Chadwick:

>>> Please provide "gpart show -p ada1" output, both here and in the PR,
>>> if you could.
>>
>> =>        63  1953525105    ada1  MBR  (931G)
>>           63   209714337  ada1s1  freebsd  [active]  (100G)
>>    209714400         800          - free -  (400k)
>>    209715200    71680000  ada1s2  ntfs  (34G)
>>    281395200       15405          - free -  (7.5M)
>>    281410605   488263545  ada1s3  linux-data  (232G)
>>    769674150  1183851018          - free -  (564G)

Thanks for all the useful information provided so far (including further
down).  I know some of that already, but am not going to complain
because it is very useful in the logs.

> The problem here is that I cannot guarantee you that alignment is
> the problem.  The performance impact of writes to partitions which are
> non-aligned is quite high, and NCQ just exacerbates this problem.  I
> would love to tell you "switch to GPT and follow Warren Block's
> document***" but if your NTFS partition is Windows and is a Windows version
> older than Windows 7 GPT is not supported.

I am happy to make that realign-and-use-GPT experiment.
My Windows is "7 Professional 64-bit".

It will take me a few days because this is spare-time stuff.

> One piece of evidence that refutes my theory is that if Windows and/or
> Linux partition are something you boot into and use often, I would
> imagine NCQ would be used in both of those environments and would suffer
> from the same issue.  Although Windows tends to hide all sorts of
> transient errors from the user (sigh), Linux tends to be like FreeBSD
> with regards to such issues (on the console anyway; you wouldn't see
> such messages normally inside of X).

Now, the FreeBSD slice is the only partition on that disk that would
likely see concurrent write accesses (think "make -j8" on a quadcore
computer) which is more prone to ferret out such alignment contention.

The NTFS partition is aligned on a multi-MB boundary, so wouldn't hit
the problem anyways.

The Linux partition is in ext4 format for mostly sequential access to
files usually in excess of 10 MB each.

Linux's ext4 jumps through several hoops to end up with bulk writes,
like extents, delayed allocations (to avoid fragmentation), reordering
of data and metadata writes, serialized log writes and all that stuff,
and it would appear I am permitting it to cache writes -- Linux uses
write barriers to enforce proper ordering of journal/meta-data writes.

It would be rather hard to hit ATA taskfile timeouts, the expected rate
with which the drive needs to do a partial write is orders of magnitude
lower.

Any good "concurrent write" exercise tools for Unix that I could run on
the Linux ext4 partition that you would propose?

> If you have the time and want to put forth the effort, I would recommend
> backing up all your data on ada1, zero the first and last 1MByte of the
> drive, and then try following Warren Block's guide.  I'd just recommend
> doing this:
> 
> gpart create -s gpt ada1
> gpart add -t freebsd-ufs -b 2m ada1
> newfs -U -j /dev/ada1p1   (or remove -j if you don't want to use SUJ)

Will do.

>> - I am running with kern.cam.ada.default_timeout=5 which makes the
>> computer recover faster
> 
> I can definitely imagine cases where a drive using NCQ but doing writes
> to a non-aligned partition could take longer than 5 seconds to respond
> to an ATA CDB (this is different than a SATA or AHCI layer timeout).  I am
> not telling you "change this back to 30", but it might not be helping
> your situation at all given my above theory.

My feeling is that the stalls are mostly from the error handler and the
overall time the drive is "frozen" gets shorter. If it had not _felt_
faster, I'd not have left that in sysctl.conf in the first place.

> Finally: could you please provide output from "smartctl -x /dev/ada1"?
> I would like to rule out any possibility of your drive having some other
> kind of issue that might cause it to go catatonic.  Thanks.

I have fetched the data with Linux this time (should not make a
difference as it's all drive internal data, not host OS stuff).

Looks sane to me, <http://people.freebsd.org/~mandree/smartctl.log>.
I'll be happy to refetch this data with a more current smartctl version
under FreeBSD if required.

> 
> 
> ** -- http://www.seagate.com/files/www-content/support-content/documentation/samsung/tech-specs/eco_greenf2.pdf
> 
> *** -- http://www.wonkity.com/~wblock/docs/html/ssd.html
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130404/4dee12ee/attachment.sig>