Tejun Heo wrote:
Once the sysfs attr's actually work, I'll probably re-do my hdparm
stuff to detect use them when available, avoiding the need for libata
to snoop passthrough commands. But Jeff may (or not) want to snoop
anyway.
As a workaround for now, Ric is using the ugly hack attached here.
Cheers
With this patch, I can get the write cache to change properly, but I
still see rates that are "too fast" until I disable the queuing as
well. I think that the barriers are supposed to work with NCQ
enabled, but might there be a trace of the old "disable" barrier
support if queuing is on left somewhere?
I think the easiest way to verify basic things are working is by
booting the machine with write cache enabled.
You can measure the rate with barriers enabled or not on a per file
system instance (ie, mount barrier=none) to get a quick baseline. This
rate has been an extremely accurate way for us to diagnose big issues
(like the barrier is just not working - you get hundreds of files/sec
instead of tens of files/sec ;-)) or subtle ones like regressions in
disk firmware.
For us, the broader issue is that the rest of the company only uses
drives with write cache disabled & as the small group, we have to dip
into their manufacturing stream and use the parts as the rest of the
company dictates. Being able to toggle the write cache (before mounting
a file system) is one of the weird edge cases that few others care about ;-)
Also, disabling the queue via setting
/sys/class/scsi_disk/4\:0\:0\:0/device/queue_depth does not seem to
take effect unless I unmount the file system & remount. I will poke
around to see if reiserfs is disabling with queuing enabled & only
reenables on a fresh mount...
I don't think you're supposed to change cache setting underneath a
live FS.
Makes sense - I don't see logic in reiserfs at least that looks at (or
knows) about anything other than "did my barrier op" fail. When that
happens, it should log a "disabling barriers for /dev/sdX" and leave
them disabled. I did not see that message so I suspect that we still
have some lower level mechanism.
A different discussion is what we should do or log when we detect this -
i.e., write cache enabled and barrier ops not supported (disable write
cache? log a scarier message? ignore it?). Today's behavior is
probably what most home users want (run as fast as I can, absolute data
integrity over power failures not a big deal) but not the right behavior
for critical data (i.e., forget performance, make sure my data is always
safe ).
I will keep poking at this today to try and clarify things.
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
