tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL
2017-03-12 11:15 GMT+01:00 Edgar Fuß <ef%math.uni-bonn.de@localhost>:
> Some comments as I probably count as one of the larger WAPBL consumers (we
> have ~150 employee's Home and Mail on NFS on FFS2+WAPBL on RAIDframe on SAS):
I've not changed the code in RF to pass the cache flags, so the patch
doesn't actually enable FUA there. Mainly because disks come and go
and I'm not aware of mechanism to make WAPBL aware of such changes. It
would be easy to add the passthrough if needed, can use code from
DIOCCACHESYNC handling. Or maybe we could assume that everybody uses
same kind of disks in raid volume :)
Maybe we could handle this just by polling - i.e. adding some flag
like DKCACHE_VOLATILE for use in RF, and WAPBL code could implement a
periodic callout checking for changes.
The SAS drivers attach normal sd(4), right? My patch only updates
sd(4) and nvme(4) to support the flags. Of course it would be neat to
get anything else on board, if docs and testers are available. It
would good to first test it on real hardware, to see if there is
actual benefit.
> Also, I remember each journal flush to actually cause two cache syncs, one
> before and one after writing the actual data.
Yes. It needs to do this because it needs to make sure that journal
data are saved before we save the journal commit block. Implicitly,
the pre-commit flush also makes sure that all asynchronously written
metadata updates are written to the media, before the commit makes
them impossible to replay. The pre-commit sync can be avoided by
adding a checksum to journal commit record - I have a plan on adding
this sometime later, too.
> JD> it adds (another) incentive to actually integrate AHCI NCQ support
> What about SCSI TCQ? I seem to remember all that flushing could be avoided
> if the FS used queueing. DHs comments on barriers seem to second that.
Even SCSI ORDERED tags wouldn't help to avoid the need for cache flushes.
Jaromir
Home |
Main Index |
Thread Index |
Old Index