FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Cluster Development

 
 
LinkBack Thread Tools
 
Old 06-07-2010, 03:39 PM
Steven Whitehouse
 
Default 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>

diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
index b5d7363..8fcbce4 100644
--- a/fs/gfs2/incore.h
+++ b/fs/gfs2/incore.h
@@ -460,6 +460,7 @@ enum {
SDF_NOBARRIERS = 3,
SDF_NORECOVERY = 4,
SDF_DEMOTE = 5,
+ SDF_NOJOURNALID = 6,
};

#define GFS2_FSNAME_LEN 256
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index 3593b3a..45a4a36 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -76,7 +76,7 @@ static struct gfs2_sbd *init_sbd(struct super_block *sb)

sb->s_fs_info = sdp;
sdp->sd_vfs = sb;
-
+ set_bit(SDF_NOJOURNALID, &sdp->sd_flags);
gfs2_tune_init(&sdp->sd_tune);

init_waitqueue_head(&sdp->sd_glock_wait);
@@ -1050,7 +1050,8 @@ static int gfs2_lm_mount(struct gfs2_sbd *sdp, int silent)
ret = match_int(&tmp[0], &option);
if (ret || option < 0)
goto hostdata_error;
- ls->ls_jid = option;
+ if (test_and_clear_bit(SDF_NOJOURNALID, &sdp->sd_flags))
+ ls->ls_jid = option;
break;
case Opt_id:
/* Obsolete, but left for backward compat purposes */
@@ -1102,6 +1103,24 @@ void gfs2_lm_unmount(struct gfs2_sbd *sdp)
lm->lm_unmount(sdp);
}

+static int gfs2_journalid_wait(void *word)
+{
+ if (signal_pending(current))
+ return -EINTR;
+ schedule();
+ return 0;
+}
+
+static int wait_on_journal(struct gfs2_sbd *sdp)
+{
+ if (sdp->sd_args.ar_spectator)
+ return 0;
+ if (sdp->sd_lockstruct.ls_ops->lm_mount == NULL)
+ return 0;
+
+ return wait_on_bit(&sdp->sd_flags, SDF_NOJOURNALID, gfs2_journalid_wait, TASK_INTERRUPTIBLE);
+}
+
void gfs2_online_uevent(struct gfs2_sbd *sdp)
{
struct super_block *sb = sdp->sd_vfs;
@@ -1194,6 +1213,10 @@ static int fill_super(struct super_block *sb, struct gfs2_args *args, int silent
if (error)
goto fail_locking;

+ error = wait_on_journal(sdp);
+ if (error)
+ goto fail_sb;
+
error = init_inodes(sdp, DO);
if (error)
goto fail_sb;
diff --git a/fs/gfs2/sys.c b/fs/gfs2/sys.c
index 37f5393..d019d0d 100644
--- a/fs/gfs2/sys.c
+++ b/fs/gfs2/sys.c
@@ -325,6 +325,30 @@ static ssize_t lkfirst_show(struct gfs2_sbd *sdp, char *buf)
return sprintf(buf, "%d
", ls->ls_first);
}

+static ssize_t lkfirst_store(struct gfs2_sbd *sdp, const char *buf, size_t len)
+{
+ unsigned first;
+ int rv;
+
+ rv = sscanf(buf, "%u", &first);
+ if (rv != 1 || first > 1)
+ return -EINVAL;
+ spin_lock(&sdp->sd_jindex_spin);
+ rv = -EBUSY;
+ if (test_bit(SDF_NOJOURNALID, &sdp->sd_flags) == 0)
+ goto out;
+ rv = -EINVAL;
+ if (sdp->sd_args.ar_spectator)
+ goto out;
+ if (sdp->sd_lockstruct.ls_ops->lm_mount == NULL)
+ goto out;
+ sdp->sd_lockstruct.ls_first = first;
+ rv = 0;
+out:
+ spin_unlock(&sdp->sd_jindex_spin);
+ return rv ? rv : len;
+}
+
static ssize_t first_done_show(struct gfs2_sbd *sdp, char *buf)
{
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
@@ -377,14 +401,41 @@ static ssize_t jid_show(struct gfs2_sbd *sdp, char *buf)
return sprintf(buf, "%u
", sdp->sd_lockstruct.ls_jid);
}

+static ssize_t jid_store(struct gfs2_sbd *sdp, const char *buf, size_t len)
+{
+ unsigned jid;
+ int rv;
+
+ rv = sscanf(buf, "%u", &jid);
+ if (rv != 1)
+ return -EINVAL;
+
+ spin_lock(&sdp->sd_jindex_spin);
+ rv = -EINVAL;
+ if (sdp->sd_args.ar_spectator)
+ goto out;
+ if (sdp->sd_lockstruct.ls_ops->lm_mount == NULL)
+ goto out;
+ rv = -EBUSY;
+ if (test_and_clear_bit(SDF_NOJOURNALID, &sdp->sd_flags) == 0)
+ goto out;
+ sdp->sd_lockstruct.ls_jid = jid;
+ smp_mb__after_clear_bit();
+ wake_up_bit(&sdp->sd_flags, SDF_NOJOURNALID);
+ rv = 0;
+out:
+ spin_unlock(&sdp->sd_jindex_spin);
+ return rv ? rv : len;
+}
+
#define GDLM_ATTR(_name,_mode,_show,_store)
static struct gfs2_attr gdlm_attr_##_name = __ATTR(_name,_mode,_show,_store)

GDLM_ATTR(proto_name, 0444, proto_name_show, NULL);
GDLM_ATTR(block, 0644, block_show, block_store);
GDLM_ATTR(withdraw, 0644, withdraw_show, withdraw_store);
-GDLM_ATTR(jid, 0444, jid_show, NULL);
-GDLM_ATTR(first, 0444, lkfirst_show, NULL);
+GDLM_ATTR(jid, 0644, jid_show, jid_store);
+GDLM_ATTR(first, 0644, lkfirst_show, lkfirst_store);
GDLM_ATTR(first_done, 0444, first_done_show, NULL);
GDLM_ATTR(recover, 0600, NULL, recover_store);
GDLM_ATTR(recover_done, 0444, recover_done_show, NULL);
@@ -564,7 +615,7 @@ static int gfs2_uevent(struct kset *kset, struct kobject *kobj,

add_uevent_var(env, "LOCKTABLE=%s", sdp->sd_table_name);
add_uevent_var(env, "LOCKPROTO=%s", sdp->sd_proto_name);
- if (!sdp->sd_args.ar_spectator)
+ if (!test_bit(SDF_NOJOURNALID, &sdp->sd_flags))
add_uevent_var(env, "JOURNALID=%u", sdp->sd_lockstruct.ls_jid);
if (gfs2_uuid_valid(uuid))
add_uevent_var(env, "UUID=%pUB", uuid);
 
Old 06-07-2010, 05:34 PM
David Teigland
 
Default GFS2: Wait for journal id on mount if not specified on mount command line

On Mon, Jun 07, 2010 at 04:39:09PM +0100, Steven Whitehouse wrote:
>
> 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)

Proposed is the way it originally worked. I switched to using Current
back in 2005... unfortunately I don't remember all the specific reasons,
but I'm pretty sure it was the error/edge cases that were better handled
without sitting in the kernel early in the process. (Especially when you
combine simultaneous mounting / mount failures / node failures / recovery.)

A couple obvious questions from the start...
- What if gfs_controld isn't running?
- Won't processes start to access the fs and block during this intermediate
time between mount(2) and getting a journal id? All of those processes
now need errors returned if gfs_controld returns an error instead of a
journal id.

Another way to compare them:

Current:
- get all the userspace/clustering-related/error-laden overhead sorted out
- then, at the very end, pull the kernel fs into the picture
- collect the result of mount(2) in userpsace, which is almost always
"success"

Proposed:
- pull the kernel fs into the picture
- transition to userspace to sort out all the clustering-related /
error-laden overhead
- get back to the kernel with the result
- collect the result of mount(2) in userspace

The further you get before you encounter errors, the harder they are to
handle. You want most errors to happen earlier, with fewer entities
involved, so backing out is easier to do.

IIRC, nfs recently moved to using a mount helper after *not* using one for
many years. It would be interesting to ask them about their motivations.


> 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.

That's not an "advantage" of new versus old, which is the missing bit of
information here. I'm not against changing it per se, but it seems we'd
want some substantial advantage before going to all the effort of changing
such a delicate area that has worked quite well for the past 5 years.

There's room for real, major improvements in this whole area, but you're
barking up the wrong tree. gfs_controld has always been far too complex.
But it's *not* a result of current mount helper scheme. It is a direct
result of gfs_controld being required to do jobs that gfs (in kernel)
should probably handle itself: allocating journal id's, coordinating who
does journal recovery, coordinating first mounter recovery, sorting out
valid combinations of mount options from different nodes, keeping track of
recovered journals vs journals that haven't been recovered, coordinating
when all journals have been successfully recovered so that normal fs
access can be continued.

If you want to do something that's meaningful and beneficial in this area,
you need to look at moving *those* things from gfs_controld into gfs.
Ocfs2 is a good example here, it handles almost all of that stuff in the
kernel, and leaves only what's really necessary for ocfs2_controld.

In fact, this could be a perfect area for gfs2/ocfs2 unification: adopt a
single fs_controld, single mount/unmount scheme, single node failure/recovery
notification scheme, single journal id/allocation scheme.

Dave
 
Old 06-08-2010, 08:34 AM
Steven Whitehouse
 
Default GFS2: Wait for journal id on mount if not specified on mount command line

Hi,

On Mon, 2010-06-07 at 12:34 -0500, David Teigland wrote:
> On Mon, Jun 07, 2010 at 04:39:09PM +0100, Steven Whitehouse wrote:
> >
> > 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)
>
> Proposed is the way it originally worked. I switched to using Current
> back in 2005... unfortunately I don't remember all the specific reasons,
> but I'm pretty sure it was the error/edge cases that were better handled
> without sitting in the kernel early in the process. (Especially when you
> combine simultaneous mounting / mount failures / node failures / recovery.)
>
> A couple obvious questions from the start...
> - What if gfs_controld isn't running?
It will hang until mount is killed, where upon it will clean up and exit
gracefully.

> - Won't processes start to access the fs and block during this intermediate
> time between mount(2) and getting a journal id? All of those processes
> now need errors returned if gfs_controld returns an error instead of a
> journal id.
Nothing can access the fs until mount completes successfully.

>
> Another way to compare them:
>
> Current:
> - get all the userspace/clustering-related/error-laden overhead sorted out
> - then, at the very end, pull the kernel fs into the picture
> - collect the result of mount(2) in userpsace, which is almost always
> "success"
>
But that isn't the way it works currently. The first mount result (and
recovery results) are collected via uevents, even in the current scheme.

> Proposed:
> - pull the kernel fs into the picture
> - transition to userspace to sort out all the clustering-related /
> error-laden overhead
> - get back to the kernel with the result
> - collect the result of mount(2) in userspace
>
> The further you get before you encounter errors, the harder they are to
> handle. You want most errors to happen earlier, with fewer entities
> involved, so backing out is easier to do.
>
There isn't a great difference between the error handling in either
case. There is one extra case for the kernel to handle, that of getting
an invalid journal id, or not getting a journal id at all. The actual
sequence of events is pretty similar, the main difference being that
gfs_controld talks directly to the fs in all cases, rather than using
mount.gfs2 as in intermediate point in the communications. Since
gfs_controld already communicates directly with the fs anyway for a
number of other reasons, it seems reasonable to cut out the middle man
in this one remaining case where we have the mount helper in order to
simplify the system.

> IIRC, nfs recently moved to using a mount helper after *not* using one for
> many years. It would be interesting to ask them about their motivations.
>
We can ask by all means, but I'm not sure its relevant to this
situation.

>
> > 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.
>
> That's not an "advantage" of new versus old, which is the missing bit of
> information here. I'm not against changing it per se, but it seems we'd
> want some substantial advantage before going to all the effort of changing
> such a delicate area that has worked quite well for the past 5 years.
>
> There's room for real, major improvements in this whole area, but you're
> barking up the wrong tree. gfs_controld has always been far too complex.
> But it's *not* a result of current mount helper scheme. It is a direct
> result of gfs_controld being required to do jobs that gfs (in kernel)
> should probably handle itself: allocating journal id's, coordinating who
> does journal recovery, coordinating first mounter recovery, sorting out
> valid combinations of mount options from different nodes, keeping track of
> recovered journals vs journals that haven't been recovered, coordinating
> when all journals have been successfully recovered so that normal fs
> access can be continued.
>
> If you want to do something that's meaningful and beneficial in this area,
> you need to look at moving *those* things from gfs_controld into gfs.
> Ocfs2 is a good example here, it handles almost all of that stuff in the
> kernel, and leaves only what's really necessary for ocfs2_controld.
>
> In fact, this could be a perfect area for gfs2/ocfs2 unification: adopt a
> single fs_controld, single mount/unmount scheme, single node failure/recovery
> notification scheme, single journal id/allocation scheme.
>
> Dave
>

The question is then, whether this could be made backward compatible
with what we already have. I'm not sure how we could allocate journal
ids in the kernel since we have no communication mechanism other than
the locking.

Getting rid of mount.gfs2 results in there being one fewer userland
program to maintain. It also removes the one major dependency between
gfs2-utils and the cluster packages making builds much easier. In time
we can simplify gfs_controld too since it would no longer need the code
to talk to mount.gfs2.

Some of these changes are a long way off at the moment, since it will
take some time before we can reasonably make all of the userland
changes. In the mean time though, I think it is important to get the
kernel changes in as soon as we can, in order to give us the opportunity
of making the userland changes at a later date,

Steve.
 
Old 06-08-2010, 08:36 AM
Christoph Hellwig
 
Default GFS2: Wait for journal id on mount if not specified on mount command line

On Mon, Jun 07, 2010 at 12:34:14PM -0500, David Teigland wrote:
> IIRC, nfs recently moved to using a mount helper after *not* using one for
> many years. It would be interesting to ask them about their motivations.

That's not correct at all. NFS has required special mount code since
day 1 and continues to do so. The only change is that this code used
to be built into the mount binary and now has moved to a helper in the
nfs-tools package.
 
Old 06-08-2010, 08:37 PM
David Teigland
 
Default GFS2: Wait for journal id on mount if not specified on mount command line

On Tue, Jun 08, 2010 at 09:34:52AM +0100, Steven Whitehouse wrote:
> > A couple obvious questions from the start...
> > - What if gfs_controld isn't running?
> It will hang until mount is killed, where upon it will clean up and exit
> gracefully.

Right, so instead of failing with an error, it hangs and requires a user
to intervene and kill it. That's not good.

> > - Won't processes start to access the fs and block during this intermediate
> > time between mount(2) and getting a journal id? All of those processes
> > now need errors returned if gfs_controld returns an error instead of a
> > journal id.
> Nothing can access the fs until mount completes successfully.

Right, but does the access block indefinately waiting for all the userland
nonsense to complete?

> > Current:
> > - get all the userspace/clustering-related/error-laden overhead sorted out
> > - then, at the very end, pull the kernel fs into the picture
> > - collect the result of mount(2) in userpsace, which is almost always
> > "success"
> >
> But that isn't the way it works currently. The first mount result (and
> recovery results) are collected via uevents, even in the current scheme.
>
> > Proposed:
> > - pull the kernel fs into the picture
> > - transition to userspace to sort out all the clustering-related /
> > error-laden overhead
> > - get back to the kernel with the result
> > - collect the result of mount(2) in userspace
> >
> > The further you get before you encounter errors, the harder they are to
> > handle. You want most errors to happen earlier, with fewer entities
> > involved, so backing out is easier to do.
> >
> There isn't a great difference between the error handling in either
> case. There is one extra case for the kernel to handle, that of getting
> an invalid journal id, or not getting a journal id at all. The actual
> sequence of events is pretty similar, the main difference being that
> gfs_controld talks directly to the fs in all cases, rather than using
> mount.gfs2 as in intermediate point in the communications. Since
> gfs_controld already communicates directly with the fs anyway for a
> number of other reasons, it seems reasonable to cut out the middle man
> in this one remaining case where we have the mount helper in order to
> simplify the system.

My comments on really simplifying things are at the end; this just
rearranges the complexity. If we're going to take the dive into reworking
this code, at least make it worth the effort.

> The question is then, whether this could be made backward compatible
> with what we already have. I'm not sure how we could allocate journal
> ids in the kernel since we have no communication mechanism other than
> the locking.

The dlm should work fine. You'd want to move all the journal related
stuff into gfs2: allocating jid, knowing which jid's are used by which
nodes, knowing which journals need recovery, etc. Ocfs2 does all this
stuff itself; you may be able to copy a bunch of it (or share!)

> Getting rid of mount.gfs2 results in there being one fewer userland
> program to maintain. It also removes the one major dependency between
> gfs2-utils and the cluster packages making builds much easier. In time
> we can simplify gfs_controld too since it would no longer need the code
> to talk to mount.gfs2.
>
> Some of these changes are a long way off at the moment, since it will
> take some time before we can reasonably make all of the userland
> changes. In the mean time though, I think it is important to get the
> kernel changes in as soon as we can, in order to give us the opportunity
> of making the userland changes at a later date,

The changes you're suggesting may seem minor to you, but they involve
changing how very core and delicate interactions work. It's senseless
to change that kind of stuff without a very good reason. Serious
simplification would qualify, but rearranging the deck chairs doesn't.

Dave
 
Old 06-09-2010, 08:02 AM
Steven Whitehouse
 
Default GFS2: Wait for journal id on mount if not specified on mount command line

Hi,

On Tue, 2010-06-08 at 15:37 -0500, David Teigland wrote:
> On Tue, Jun 08, 2010 at 09:34:52AM +0100, Steven Whitehouse wrote:
> > > A couple obvious questions from the start...
> > > - What if gfs_controld isn't running?
> > It will hang until mount is killed, where upon it will clean up and exit
> > gracefully.
>
> Right, so instead of failing with an error, it hangs and requires a user
> to intervene and kill it. That's not good.
>
Well we could make it time out, but I fail to see why its not good. They
are not going to be able to mount the fs anyway, given that this is only
going to occur when gfs_controld is not configured.

> > > - Won't processes start to access the fs and block during this intermediate
> > > time between mount(2) and getting a journal id? All of those processes
> > > now need errors returned if gfs_controld returns an error instead of a
> > > journal id.
> > Nothing can access the fs until mount completes successfully.
>
> Right, but does the access block indefinately waiting for all the userland
> nonsense to complete?
>
Yes, although we could make it timeout, but I'm not convinced that we
need to do that.

> > > Current:
> > > - get all the userspace/clustering-related/error-laden overhead sorted out
> > > - then, at the very end, pull the kernel fs into the picture
> > > - collect the result of mount(2) in userpsace, which is almost always
> > > "success"
> > >
> > But that isn't the way it works currently. The first mount result (and
> > recovery results) are collected via uevents, even in the current scheme.
> >
> > > Proposed:
> > > - pull the kernel fs into the picture
> > > - transition to userspace to sort out all the clustering-related /
> > > error-laden overhead
> > > - get back to the kernel with the result
> > > - collect the result of mount(2) in userspace
> > >
> > > The further you get before you encounter errors, the harder they are to
> > > handle. You want most errors to happen earlier, with fewer entities
> > > involved, so backing out is easier to do.
> > >
> > There isn't a great difference between the error handling in either
> > case. There is one extra case for the kernel to handle, that of getting
> > an invalid journal id, or not getting a journal id at all. The actual
> > sequence of events is pretty similar, the main difference being that
> > gfs_controld talks directly to the fs in all cases, rather than using
> > mount.gfs2 as in intermediate point in the communications. Since
> > gfs_controld already communicates directly with the fs anyway for a
> > number of other reasons, it seems reasonable to cut out the middle man
> > in this one remaining case where we have the mount helper in order to
> > simplify the system.
>
> My comments on really simplifying things are at the end; this just
> rearranges the complexity. If we're going to take the dive into reworking
> this code, at least make it worth the effort.
>
> > The question is then, whether this could be made backward compatible
> > with what we already have. I'm not sure how we could allocate journal
> > ids in the kernel since we have no communication mechanism other than
> > the locking.
>
> The dlm should work fine. You'd want to move all the journal related
> stuff into gfs2: allocating jid, knowing which jid's are used by which
> nodes, knowing which journals need recovery, etc. Ocfs2 does all this
> stuff itself; you may be able to copy a bunch of it (or share!)
>
OCFS2 appears to keep the journal state (wrt to allocation to nodes and
also recovery state) on disk. Whilst that might well be sensible, it
would be rather tricky to try and introduce that at this stage. It
couldn't possibly be backward compatible after that change, since older
nodes would not know how to read that information, and would thus still
be reliant on the existing infrastructure.

I don't want to rule out making a change if there is a sensible way to
implement it, but its not obvious to me how we'd do that at the moment.

> > Getting rid of mount.gfs2 results in there being one fewer userland
> > program to maintain. It also removes the one major dependency between
> > gfs2-utils and the cluster packages making builds much easier. In time
> > we can simplify gfs_controld too since it would no longer need the code
> > to talk to mount.gfs2.
> >
> > Some of these changes are a long way off at the moment, since it will
> > take some time before we can reasonably make all of the userland
> > changes. In the mean time though, I think it is important to get the
> > kernel changes in as soon as we can, in order to give us the opportunity
> > of making the userland changes at a later date,
>
> The changes you're suggesting may seem minor to you, but they involve
> changing how very core and delicate interactions work. It's senseless
> to change that kind of stuff without a very good reason. Serious
> simplification would qualify, but rearranging the deck chairs doesn't.
>
> Dave
>

This is a serious simplification. We lose a dependency between packages
and at the same time, we have one less program to maintain. Making this
change doesn't preclude further changes if we can then work out how to
implement them in a backward compatible way.

I didn't claim that the change was minor, but it is certainly a lot less
invasive than your suggestion of replacing the whole system. Thats not
to say I'm against doing that, but I'd prefer to do it carefully, one
bit at a time,

Steve.
 

Thread Tools




All times are GMT. The time now is 09:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org