[Ocfs2-devel] [PATCH] ocfs2 support for blkid utility

[Ocfs2-devel] [PATCH] ocfs2 support for blkid utility

[Rusty Lynch]

In a an email thread on the Data Center Linux (DCL) working group mailing
list about a proposed requirement for persistant device naming, Theodore Ts'o
noted that his blkid utility in the e2fsprog package could be used as part
of a persistent device naming implementation.

<<<<<<<<<<<<<< CUT 

On Tue, Feb 03, 2004@08:21:33AM -0800, Rusty Lynch wrote:
> 
> Can you point me to some documentation on how to add support for other 
> filesystems.  I just recently started working with ocfs, and it looks 
> like blkid is not picking up and partitions formated for ocfs.
> 

No documentation, I'm afraid, although adding support for ocfs should
be fairly straightforward.  The relevant file is
e2fsprogs/lib/blkid/probe.c.  If the filesystem has a straightforward
magic number, it can just be placed in the blk_magic type array:

/*
 * Various filesystem magics that we can check for.  Note that kboff and
 * sboff are in kilobytes and bytes respectively.  All magics are in
 * byte strings so we don't worry about endian issues.
 */
static struct blkid_magic type_array[] = {
/*  type     kboff   sboff len  magic			probe */
	...
  { "xfs",	 0,	 0,  4, "XFSB",			probe_xfs },
	...
}

The probe function (probe_xfs in this case) can also be used to do a
more refined test.  The probe function is responsible for setting the
label and uuid information for the filesystem, or else returning a
non-zero value if it turns out that the filesystem is not of the
specified type.  lib/blkid/probe.c probably could be more paranoid
about identifying filesystems, but to date no one has reported any
false positives so I haven't bothered to put in more stringent tests.
(See the probe_reiserfs() function for an example of the sort of extra
testing that can be done to make sure the superblock is consistent.)
As always, patches are welcome.  :-)

						- Ted

P.S.  I'm about to release a new e2fsprogs release soon, so if you
have some additional filesystems that should be added (blkid currently
supports ext2, ext3, jbd, jfs, xfs, reiserfs, minix, vfat, msdos,
ntfs, hfs, vxfs, hpfs, sysv, romfs, bfs, cramfs, qnx4, udf, iso9660,
and swap, with LABEL and/or UUID support for all filesystems that
support such labelling), please let me know.  I'm aiming for blkid to
be as complete as possible.

>>>>>>>>>>>>>> CUT

So... I downloaded the e2fsprog source tree and hacked the following
patch that adds ocfs2 support.

In the probe_ocfs() function, buf contains the first kbytes of data
from the disk, and I just grab the label, suggested mount point, and
UUID by indexing into buf.

Some of the other probe functions define their super block structure
in an e2fsprog header file, and then just cast buf to their own 
super block.  Since ocfs2 structures are considerably more complex, 
I just went with the offset method.

This code would totally break if ocfs2 changes the layout of the first
kbyte on disk.  Are there any plans to change this?

Would anyone have a problem with me submitting this to the e2fsprogs
project?

    --rusty

--- probe.c	2004-02-03 20:18:42.000000000 -0800
+++ /home/rusty/probe.c	2004-02-03 20:21:50.000000000 -0800
@@ -312,6 +312,27 @@
 	return 1;
 }
 
+static int probe_ocfs(int fd __BLKID_ATTR((unused)), 
+		      blkid_cache cache __BLKID_ATTR((unused)), 
+		      blkid_dev dev,
+		      struct blkid_magic *id __BLKID_ATTR((unused)), 
+		      unsigned char *buf)
+{
+	char *label = 0;
+	char *mount_point = 0;
+	
+	if (strlen((char *) (buf + 0x230)))
+		label = (char *) (buf + 0x230);	
+	blkid_set_tag(dev, "LABEL", label, 64);
+	
+	if (strlen((char *) (buf + 0x88)))
+		mount_point = (char *) (buf + 0x88);	
+	blkid_set_tag(dev, "MOUNT", mount_point, 128);
+
+	set_uuid(dev, (char *)(buf + 0x272));
+	return 0;
+}
+
 /*
  * BLKID_BLK_OFFS is at least as large as the highest bim_kboff defined
  * in the type_array table below + bim_kbalign.
@@ -371,6 +392,7 @@
   { "swap",	 0, 0x1ff6, 10, "SWAPSPACE2",		0 },
   { "swap",	 0, 0x3ff6, 10, "SWAP-SPACE",		0 },
   { "swap",	 0, 0x3ff6, 10, "SWAPSPACE2",		0 },
+  { "ocfs2",	 0,	 8,  9,	 "OracleCFS",  probe_ocfs },
   {   NULL,	 0,	 0,  0, NULL,			NULL }
 };
 

[Ocfs2-devel] [PATCH] ocfs2 support for blkid utility

[Wim Coekaerts]

its actually in the redhat mount stuff, you can mount by label etc
afaik it's in the standard one too, I remember even seeing it in
manpages

On Tue, Feb 03, 2004 at 08:48:22PM -0800, Rusty Lynch wrote:
> In a an email thread on the Data Center Linux (DCL) working group mailing
> list about a proposed requirement for persistant device naming, Theodore Ts'o
> noted that his blkid utility in the e2fsprog package could be used as part
> of a persistent device naming implementation.
> 
> <<<<<<<<<<<<<< CUT 
> 
> On Tue, Feb 03, 2004 at 08:21:33AM -0800, Rusty Lynch wrote:
> > 
> > Can you point me to some documentation on how to add support for other 
> > filesystems.  I just recently started working with ocfs, and it looks 
> > like blkid is not picking up and partitions formated for ocfs.
> > 
> 
> No documentation, I'm afraid, although adding support for ocfs should
> be fairly straightforward.  The relevant file is
> e2fsprogs/lib/blkid/probe.c.  If the filesystem has a straightforward
> magic number, it can just be placed in the blk_magic type array:
> 
> /*
>  * Various filesystem magics that we can check for.  Note that kboff and
>  * sboff are in kilobytes and bytes respectively.  All magics are in
>  * byte strings so we don't worry about endian issues.
>  */
> static struct blkid_magic type_array[] = {
> /*  type     kboff   sboff len  magic			probe */
> 	...
>   { "xfs",	 0,	 0,  4, "XFSB",			probe_xfs },
> 	...
> }
> 
> The probe function (probe_xfs in this case) can also be used to do a
> more refined test.  The probe function is responsible for setting the
> label and uuid information for the filesystem, or else returning a
> non-zero value if it turns out that the filesystem is not of the
> specified type.  lib/blkid/probe.c probably could be more paranoid
> about identifying filesystems, but to date no one has reported any
> false positives so I haven't bothered to put in more stringent tests.
> (See the probe_reiserfs() function for an example of the sort of extra
> testing that can be done to make sure the superblock is consistent.)
> As always, patches are welcome.  :-)
> 
> 						- Ted
> 
> P.S.  I'm about to release a new e2fsprogs release soon, so if you
> have some additional filesystems that should be added (blkid currently
> supports ext2, ext3, jbd, jfs, xfs, reiserfs, minix, vfat, msdos,
> ntfs, hfs, vxfs, hpfs, sysv, romfs, bfs, cramfs, qnx4, udf, iso9660,
> and swap, with LABEL and/or UUID support for all filesystems that
> support such labelling), please let me know.  I'm aiming for blkid to
> be as complete as possible.
> 
> >>>>>>>>>>>>>> CUT
> 
> So... I downloaded the e2fsprog source tree and hacked the following
> patch that adds ocfs2 support.
> 
> In the probe_ocfs() function, buf contains the first kbytes of data
> from the disk, and I just grab the label, suggested mount point, and
> UUID by indexing into buf.
> 
> Some of the other probe functions define their super block structure
> in an e2fsprog header file, and then just cast buf to their own 
> super block.  Since ocfs2 structures are considerably more complex, 
> I just went with the offset method.
> 
> This code would totally break if ocfs2 changes the layout of the first
> kbyte on disk.  Are there any plans to change this?
> 
> Would anyone have a problem with me submitting this to the e2fsprogs
> project?
> 
>     --rusty
> 
> --- probe.c	2004-02-03 20:18:42.000000000 -0800
> +++ /home/rusty/probe.c	2004-02-03 20:21:50.000000000 -0800
> @@ -312,6 +312,27 @@
>  	return 1;
>  }
>  
> +static int probe_ocfs(int fd __BLKID_ATTR((unused)), 
> +		      blkid_cache cache __BLKID_ATTR((unused)), 
> +		      blkid_dev dev,
> +		      struct blkid_magic *id __BLKID_ATTR((unused)), 
> +		      unsigned char *buf)
> +{
> +	char *label = 0;
> +	char *mount_point = 0;
> +	
> +	if (strlen((char *) (buf + 0x230)))
> +		label = (char *) (buf + 0x230);	
> +	blkid_set_tag(dev, "LABEL", label, 64);
> +	
> +	if (strlen((char *) (buf + 0x88)))
> +		mount_point = (char *) (buf + 0x88);	
> +	blkid_set_tag(dev, "MOUNT", mount_point, 128);
> +
> +	set_uuid(dev, (char *)(buf + 0x272));
> +	return 0;
> +}
> +
>  /*
>   * BLKID_BLK_OFFS is at least as large as the highest bim_kboff defined
>   * in the type_array table below + bim_kbalign.
> @@ -371,6 +392,7 @@
>    { "swap",	 0, 0x1ff6, 10, "SWAPSPACE2",		0 },
>    { "swap",	 0, 0x3ff6, 10, "SWAP-SPACE",		0 },
>    { "swap",	 0, 0x3ff6, 10, "SWAPSPACE2",		0 },
> +  { "ocfs2",	 0,	 8,  9,	 "OracleCFS",  probe_ocfs },
>    {   NULL,	 0,	 0,  0, NULL,			NULL }
>  };
>  
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel@oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-devel

[Ocfs2-devel] [PATCH] ocfs2 support for blkid utility

[Manish Singh]

On Tue, Feb 03, 2004 at 08:48:22PM -0800, Rusty Lynch wrote:
> So... I downloaded the e2fsprog source tree and hacked the following
> patch that adds ocfs2 support.
> 
> In the probe_ocfs() function, buf contains the first kbytes of data
> from the disk, and I just grab the label, suggested mount point, and
> UUID by indexing into buf.
> 
> Some of the other probe functions define their super block structure
> in an e2fsprog header file, and then just cast buf to their own 
> super block.  Since ocfs2 structures are considerably more complex, 
> I just went with the offset method.

It'd be cleaner to declare a couple structs in probe.h and use then in
probe.c, similar to what I did for mount in:

http://oss.oracle.com/projects/ocfs/src/trunk/patches/mountocfslabel.diff

Using offsets directly is rather cryptic.

> This code would totally break if ocfs2 changes the layout of the first
> kbyte on disk.  Are there any plans to change this?

No changes are planned, since one goal is to maintain on-disk compatibility
with ocfs1 as much as possible.
 
> Would anyone have a problem with me submitting this to the e2fsprogs
> project?

Fine by me, if you take my suggestion above. ;)

-Manish