diff options
author | Steven Whitehouse <swhiteho@redhat.com> | 2010-06-14 10:01:30 +0100 |
---|---|---|
committer | Steven Whitehouse <swhiteho@redhat.com> | 2010-07-29 09:36:35 +0100 |
commit | ba6e93645f039bd357e04b7b9d18f4e67757725e (patch) | |
tree | 11d2d4491255cd9a298fe098f6ec52e0f3d8b577 /fs/gfs2/bmap.h | |
parent | 30116ff6c6d140bc696cc624e6d8e38f018c886e (diff) |
GFS2: Wait for journal id on mount if not specified on mount command line
This patch implements a wait for the journal id in the case that it has
not been specified on the command line. This is to allow the future
removal of the mount.gfs2 helper. The journal id would instead be
directly communicated by gfs_controld to the file system. Here is a
comparison of the two systems:
Current:
1. mount calls mount.gfs2
2. mount.gfs2 connects to gfs_controld to retrieve the journal id
3. mount.gfs2 adds the journal id to the mount command line and calls
the mount system call
4. gfs_controld receives the status of the mount request via a uevent
Proposed:
1. mount calls the mount system call (no mount.gfs2 helper)
2. gfs_controld receives a uevent for a gfs2 fs which it doesn't know
about already
3. gfs_controld assigns a journal id to it via sysfs
4. the mount system call then completes as normal (sending a uevent
according to status)
The advantage of the proposed system is that it is completely backward
compatible with the current system both at the kernel and at the
userland levels. The "first" parameter can also be set the same way,
with the restriction that it must be set before the journal id is
assigned.
In addition, if mount becomes stuck waiting for a reply from
gfs_controld which never arrives, then it is killable and will abort the
mount gracefully.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Diffstat (limited to 'fs/gfs2/bmap.h')
0 files changed, 0 insertions, 0 deletions