Hi,
I've been putting together a few comments upon the FS independent journaling
layer which has been discussed on the list recently with respect to GFS.
Also I have a question about the way that the VFS/VM is likely to
develop. I'm working with the GFS team on certain aspects of the filesystem
one of which is the port of the code for 2.2.xx to 2.4.xx+, so I'm
hoping to generate some discussion to help in planning out future directions.
1. Buffer Management
This is the key area in which GFS differs from the other journaling
implementations (that I'm aware of). The core of GFS is the g-lock
layer which is an abstraction of some underlying locking protocol
which is used to coordinate the access to the shared disk. Each
g-lock locks some object such as an inode or resource group (similar to
ext2 block groups). [For more info on this see the papers located
at http://www.globalfilesystem.org/]
The key to getting good performance is to be able to release g-locks
quickly upon a request from another node in the cluster. In order to allow
this, transactions in the file system are managed so that it is easy to
request "commit all transactions on objects covered by g-lock number X"
(which is required before the g-lock is released).
GFS can merge transactions under certain conditions, but this is left as
late as possible to allow for out-of-order commits required in order to
release locks.
2. Memory Pressure
I've read various postings on this topic, and I think GFS doesn't need
anything different from the other journaling filesystems in this area.
3. Journal Management
The GFS system at present is different from that in ext3 (for example),
but again I don't think we need anything very special in this area. Either
our current scheme, the ext3 scheme or something similar will probably be
fine for GFS. GFS normally gets the g-lock for its journal at mount time and
never releases it since the journals are arranged with one for each node. The
g-lock for the journal is there only to stop a node from mounting the
filesystem whilst its journal is being recovered by another node, so it doesn't
come under the normal g-lock scheme of other inodes.
Now to the question....
So far as I understand the discussions (on this list and in private email)
the intention is to move towards putting metadata into the page cache
(presumably in the 2.5 kernel series). What are people's thoughts upon
whether journaling should be done at the buffer or page levels in
future ? I'd assume that if the data and metadata have moved to the page
level, the journaling would too...
Please cc the gfs-devel list in any reply,
Thanks,
Steve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:35 EST