hi all
I asked Red Hat Global Support Services some questions about GFS Data
Journaling. From what Red Hat tell me, I can sumarize:
a) only benefits writes, not reads
b) cannot be applied retroactively on non-empty files (I can think of a
very cludgy way, touch newfile ; [set property using gfstool] ; cat
oldfile > newfile ; mv newfile oldfile ). but this is not something I
would like to do on 3 TB of small files
c) we would have to test extensively to tell if it is worth the effort
d) it might even make performance worse since it will place higher I/O
load on the SAN / SP.
e) it would be extremely difficult to do a representative simulation. It
might perform better on a non-starved RAID controller or SAN SP, but the
performance might drop when applying the change on our production,
starved SP.
(SP = Storage Processor, EMC speak for the thing that handles the I/O in
the SAN storage array)
E.g. in our environment at least, we can cross this off our list as an
avenue of exploration for increasing performance.
greetings
Riaan
...
Eduardo:
I have talked to one of the GFS developers regarding this issue. I'll
answer your questions one by one:
a) is it safe to do?
It is safe, but it is not recommended do be done on a production
filesystem. You should create a new filesystem and experiment with it.
b) does the change favour mostly writes?
Yes, but Beware! This change will only affect the fsync() calls. The
developer says that you will have quicker fsync() calls, BUT on the
other hand, you will have more I/O. Now, if the SAN is saturated on I/O,
or on CPU needed for I/O, then it might be that it will be actually
slower for you.
c) any ballpark performance improvement we can expect
Engineering does not give you any measurable numbers. They say that the
fsyncs are quicker because of the higher i/o, and that in some cases the
performance can be better or worse, you would need to create a test case
and see how it pans out for you.
d) I see "gfs_tool setflag jdata" will only have an effect on
zero-length files. is there any way to run "gfs_tool setflag jdata"
against existing files with some kind of copy/cat/mv operation to have
the existing mail data benefit from this changed property?
the developer says that it is not possible.
e) is there any way to see if the flag has been set on a directory /
file? (I only see setflag/clearflag operations, not any kind "getflag"
The developer says that you can run gfs_tool stat on a file, and see if
the jdata flag is active for the file:
# gfs_tool stat /mnt/gfs/x | grep jdata
jdata
inherit_jdata
Therefore you can see if the jdata, and inherit_jdata is active per inode.
As a last comment on this issue. I have asked the engineers if this
option gives any performance increase in READs. The answer is NO. So I
believe that if the system is getting maxed out on reads or 75% reads,
there is very little performance boost this feature can provide, and
might even cause drops in performance. The recommended method is to
create a test environment and see how it pans out.
begin:vcard
fn:Riaan van Niekerk
n:van Niekerk;Riaan
org:Obsidian Systems;Obsidian Red Hat Consulting
email;internet:riaan@xxxxxxxxxxxxxx
title:Systems Architect
tel;work:+27 11 792 6500
tel;fax:+27 11 792 6522
tel;cell:+27 82 921 8768
x-mozilla-html:FALSE
url:http://www.obsidian.co.za
version:2.1
end:vcard
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
