Re: [RFT] major libata update

[Ric Wheeler <ric@emc.com>]

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.