Lin Shen (lshen) wrote:
Hi Bob,
This is very good info. The CF we use has builtin wear-levelling, wonder
if this will make running GFS on top of it more resonable. Of course, if
GFS is like FAT in the way that file system structure is frequently
re-written in-place and cannot be reallocated or moved after wear
failure, then the builtin wear-levelling is not good enough.
The Resource Group information is always in the same place, so the
bitmaps that indicate block usage will always be located at the same
logical blocks of the file system.
Since we'll need to run a file system on the CF, and most likely one of
either GFS, Reiser or FAT, we'd really like to compare the extra disk
writes introduced by the various file systems. I know it's hard to get
the exact numbers, but do you think GFS is far more worse in this
regard.
Not as far as media usage is concerned. GFS and the cluster suite in
general introduce network traffic to coordinate the cluster locking,
but the writes to the media are very comparable.
BTW, is there also a big difference when GFS is running in local and
clustered mode?
Again, not as far as media usage is concerned. When GFS is running
in clustered mode, the additional overhead is due to the locking
between the nodes, which doesn't touch the media.
Last, does GFS issue any disk writes when it's idle, meaning no one is
using the file system? Do the cluster and fencing stuff also introduce
disk writes?
It depends on what you mean by "idle". If your system is sitting idle,
for the most part, no, it won't be doing anything to the disk.
It won't constantly be reading and writing areas of the media, except
for routine background things found in many file systems.
For example: The Linux page cache will take care
of flushing pages to disk when it's necessary, and possibly "idle."
Journal entries may be updated as cached pages are written to disk.
Cached quota changes may be written. Unlinked inodes are deallocated.
The fstat information (i.e. for "df") may be synched up occasionally.
But this is not a lot of overhead and they would have to happen anyway.
Lin
Regards,
Bob Peterson
Red Hat Cluster Suite
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
