[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] [RFC] gfs2: Add sb and rgrp fields to aid fsck and grow


Yes - if its easy enough to implement using the first rg as an indicator for the others, then that sounds ok to me. I'm not sure how easy that would be without looking more closely at the code though,


On 07/04/14 16:50, Andrew Price wrote:
[Didn't CC cluster-devel - re-sending]


So this conversation went dormant for a while but now that the resource group size question is out of the way (sb_rgsize definitely isn't needed) and the usage of rg_next is pretty straightforward, we still have the semantics of rg_uuid to pin down. To recap:

diff --git a/include/uapi/linux/gfs2_ondisk.h b/include/uapi/linux/gfs2_ondisk.h
index db3fdd0..e425413 100644
--- a/include/uapi/linux/gfs2_ondisk.h
+++ b/include/uapi/linux/gfs2_ondisk.h
@@ -186,10 +186,11 @@ struct gfs2_rgrp {
        __be32 rg_flags;
        __be32 rg_free;
        __be32 rg_dinodes;
-       __be32 __pad;
+       __be32 rg_next;
        __be64 rg_igeneration;
+       __u8 rg_uuid[16];

-       __u8 rg_reserved[80]; /* Several fields from gfs1 now reserved */
+       __u8 rg_reserved[64]; /* Several fields from gfs1 now reserved */


On 30/01/14 18:50, Steven Whitehouse wrote:
On Thu, 2014-01-30 at 17:31 +0000, Andrew Price wrote:
On 29/01/14 15:32, Steven Whitehouse wrote:
On Wed, 2014-01-29 at 14:47 +0000, Andrew Price wrote:
rg_uuid is intended to be the same as sb_uuid for the file system. It
can be used by fsck.gfs2, when searching for resource group headers, in order to distinguish resource groups created as part of a previous file
system on the device from resource groups in the current file system.

Again, this could be updated by writing the rgrps back to deal with
older filesystems which need to be upgraded.


That could be done as a one
off sweep, or as and when we write each rgrp. Also I wonder - if the
field is zero, we know that the rgrp is an old one that doesn't have it
set, but if someone changes the uuid at a later date, then what?

That's a good point.

we can use the uuid as a way to set it to start with (in mkfs), but
after that we'd use the value from the first rgrp to fill in later
rgrps. If the first rgrp was zero then we'd not update the other rgrps
until the first rgrp had a value in it. Or something like that... I just
want to be certain that we understand what this field will mean in all
possible cases,

Yes, unless you'd prefer a separate sb_rg_uuid field in the superblock
we should treat it differently to the sb_uuid after mkfs and only expect
the rg_uuids to be consistent with themselves. There's a corner case
where the first rgrp might have its uuid while the others still have
zero, though, which will need some more though.

I don't think we need a sb field really. We can look at the first rgrp
and if its zero, we know that we can set it to a random value, and then
update all the other rgrps to the same value. Or something along those
lines, anyway,

I agree that the sb field probably isn't required. From fsck's perspective I'm a little worried about the lack of atomicity. If we're using the first rgrp's uuid as an indicator of what the others' should be, it might be safer for gfs2 to update all of the rgrps' uuids except the first one and then update the first one, once we know the rest have been updated. Then, if the first one is still zero we know all bets are off and we shouldn't even look at rg_uuid any more because an update wasn't completed. Is that feasible/sensible?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]