[Linux-cluster] GFS Data Journaling - answers

[Riaan van Niekerk]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: riaan.vcf
Type: text/x-vcard
Size: 310 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20061026/224adeb3/attachment.vcf>