Any objections/comments on axing out old ATA stack?
mandree at FreeBSD.org
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
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)
>> - 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...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the freebsd-stable