[gpfsug-discuss] mmcrfs issue
Aaron Knister
aaron.s.knister at nasa.gov
Tue Mar 14 18:31:55 GMT 2017
On 3/14/17 2:15 PM, valdis.kletnieks at vt.edu wrote:
> On Mon, 13 Mar 2017 20:06:29 -0400, Aaron Knister said:
>> After setting the sync=always parameter to not lose data in the event of
>> a crash or power outage the write performance became unbearably slow
>> (under 100MB/s of writes for an 8+2 RAIDZ2 if I recall correctly). I
>
> Not at all surprising. Forcing a 'sync every write' has been painful for pretty
> much everything - first time I saw it was on a SunOS 3.2 box doing NFS over 3
> decades ago.
>
You know, what's interesting is when you do direct I/O to a linux md
RAID device each acknowledged I/O to the md device results in SCSI
SYNCHRONIZE CACHE commands being sent to the underlying member devices.
I consider that doing a sync of sorts after each write and as long as
everything is properly aligned you can get pretty fantastic performance
from this. No data checksums, though :(
>> I've got an RFE open with IBM
>> (https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=84994)
>> to see if the behavior of GPFS could be changed such that it would issue
>> explicit cache flushes that would allow it to work with ZFS (it might
>> even be beneficial in FPO environments too).
>
> Do you have a suggestion for how to do this without it turning into 'sync=always'
> just done at a different layer in the stack?
>
I don't think that GPFS would need to issue a sync after *every* write.
I think the key is more that GPFS is aware of the state of acknowledged
but uncommitted writes so that if there's something *really* important
to be written (i.e. an internal piece of metadata) GPFS can force it to
be committed to avoid GPFS itself becoming inconsistent. You don't want
to have to mmfsck after a power outage/crash if there were lost writes
that GPFS assumed were committed.
-Aaron
>
>
> _______________________________________________
> gpfsug-discuss mailing list
> gpfsug-discuss at spectrumscale.org
> http://gpfsug.org/mailman/listinfo/gpfsug-discuss
>
--
Aaron Knister
NASA Center for Climate Simulation (Code 606.2)
Goddard Space Flight Center
(301) 286-2776
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170314/73c5eb59/attachment-0002.sig>
More information about the gpfsug-discuss
mailing list