http://bugzilla.kernel.org/show_bug.cgi?id=6380
Martin@xxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|blocking |normal
------- Additional Comments From Martin@xxxxxxxxxxxx 2006-04-13 05:44 -------
Many thanks for your prompt answer.
Indeed, write cache should have been switched on, according to this
root@deepdance:~ -> hdparm -i /dev/hda | grep WriteCache
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
and this:
root@deepdance:~ -> cat /etc/hdparm.conf
[...]
/dev/hda {
mult_sect_io = 16
write_cache = on
dma = on
apm = 0
acoustic_management = 128
io32_support = 3
keep_settings_over_reset = on
interrupt_unmask = on
}
I know no way to query it directly.
I switched it to off immediately using hdparm -W 0 and set it to off in the
hdparm.conf file as well.
I take your comment that this should be set to off with kernel 2.6.15 as well.
Well I know SmartFilesystem for AmigaOS relies on data to be flushed to disc to
be written immediately before the call returns in order to ensure a certain
order for atomic writes. So this is the case with XFS as well?
Well ok, Documentation/block/barrier.txt sheds some light on this - just for
other readers of this bug:
"There are four cases,
i. No write-back cache. Keeping requests ordered is enough.
ii. Write-back cache but no flush operation. There's no way to
gurantee physical-medium commit order. This kind of devices can't to
I/O barriers.
iii. Write-back cache and flush operation but no FUA (forced unit
access). We need two cache flushes - before and after the barrier
request."
Ok, so either barriers on or write cache off. Got this.
"-o barrier" is a mount option? I do not find it documentated anywhere.
Any hints on why it may worked quite well with 2.6.15 but I got three
corruptions in one week with 2.6.16? Just coincidence or was there some write
cache related changes in 2.6.16? During 2.6.15 time I had quite some 3D savage
DRI driver lockups without any data loss.
I lowered severity to normal as it seems from your comment that it is a
misconfiguration on my side. Feel free to raise it again it is seems approbiate
to you. When according to hdparm -i /dev/hda the drive seems to default to
WriteCache enabled it may have severe implications. At least the default
setting should never burn any data --> kernel 2.6.17 with -o barrier on by
default.
I will test kernel 2.6.16.4 with write cache off in hdparm and when that works,
I may try with barrier on and write cache on - I am still a bit scared ATM.
When both works that bug can be closed. A hint in the xfs.txt readme would
still be in order IMHO until 2.6.17 is standard.
Hard drive in my laptop:
root@deepdance:~ -> smartctl -i /dev/hda
smartctl version 5.34 [i686-pc-linux-gnu] Copyright (C) 2002-5 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Model Family: Hitachi Travelstar 5K80 family
Device Model: HTS548060M9AT00
Serial Number: MRLB21L4G6G3DC
Firmware Version: MGBOA50A
User Capacity: 60.011.642.880 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 6
ATA Standard is: ATA/ATAPI-6 T13 1410D revision 3a
Local Time is: Thu Apr 13 14:18:21 2006 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Regards,
Martin
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|