linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Cc: "MASON,CHRISTOPHER" <CHRIS.MASON@oracle.com>
Subject: [PATCH] blkid: recognize btrfs
Date: Thu, 08 Jan 2009 15:08:16 -0600	[thread overview]
Message-ID: <49666B40.2090106@redhat.com> (raw)

Add btrfs detection to libblkid, now that the disk format should be
recognizable in the future.

# misc/blkid /tmp/fsfile 
/tmp/fsfile: LABEL="mylabel" UUID="102b07f0-0e79-4b42-8a4e-1dde418bbe6d" TYPE="btrfs" 

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

Index: e2fsprogs/lib/blkid/probe.c
===================================================================
--- e2fsprogs.orig/lib/blkid/probe.c
+++ e2fsprogs/lib/blkid/probe.c
@@ -1293,6 +1293,22 @@ static int probe_lvm2(struct blkid_probe
 
 	return 0;
 }
+
+static int probe_btrfs(struct blkid_probe *probe,
+			struct blkid_magic *id,
+			unsigned char *buf)
+{
+	struct btrfs_super_block *bs;
+	const char *label = 0;
+
+	bs = (struct btrfs_super_block *)buf;
+
+	if (strlen(bs->label))
+		label = bs->label;
+	blkid_set_tag(probe->dev, "LABEL", label, sizeof(bs->label));
+	set_uuid(probe->dev, bs->fsid, 0);
+	return 0;
+}
 /*
  * Various filesystem magics that we can check for.  Note that kboff and
  * sboff are in kilobytes and bytes respectively.  All magics are in
@@ -1386,6 +1402,7 @@ static struct blkid_magic type_array[] =
   { "lvm2pv",	 0,  0x018,  8, "LVM2 001",		probe_lvm2 },
   { "lvm2pv",	 1,  0x018,  8, "LVM2 001",		probe_lvm2 },
   { "lvm2pv",	 1,  0x218,  8, "LVM2 001",		probe_lvm2 },
+  { "btrfs",	 64,  0x40,  8, "_BHRfS_M",		probe_btrfs },
   {   NULL,	 0,	 0,  0, NULL,			NULL }
 };
 
Index: e2fsprogs/lib/blkid/probe.h
===================================================================
--- e2fsprogs.orig/lib/blkid/probe.h
+++ e2fsprogs/lib/blkid/probe.h
@@ -621,6 +621,110 @@ struct lvm2_pv_label_header {
 	__u8	pv_uuid[LVM2_ID_LEN];
 } __attribute__ ((packed));
 
+
+/*
+ * this is a very generous portion of the super block, giving us
+ * room to translate 14 chunks with 3 stripes each.
+ */
+#define BTRFS_SYSTEM_CHUNK_ARRAY_SIZE 2048
+#define BTRFS_LABEL_SIZE 256
+#define BTRFS_UUID_SIZE 16
+#define BTRFS_FSID_SIZE 16
+#define BTRFS_CSUM_SIZE 32
+
+struct btrfs_dev_item {
+	/* the internal btrfs device id */
+	__u64 devid;
+
+	/* size of the device */
+	__u64 total_bytes;
+
+	/* bytes used */
+	__u64 bytes_used;
+
+	/* optimal io alignment for this device */
+	__u32 io_align;
+
+	/* optimal io width for this device */
+	__u32 io_width;
+
+	/* minimal io size for this device */
+	__u32 sector_size;
+
+	/* type and info about this device */
+	__u64 type;
+
+	/* expected generation for this device */
+	__u64 generation;
+
+	/*
+	 * starting byte of this partition on the device,
+	 * to allowr for stripe alignment in the future
+	 */
+	__u64 start_offset;
+
+	/* grouping information for allocation decisions */
+	__u32 dev_group;
+
+	/* seek speed 0-100 where 100 is fastest */
+	__u8 seek_speed;
+
+	/* bandwidth 0-100 where 100 is fastest */
+	__u8 bandwidth;
+
+	/* btrfs generated uuid for this device */
+	__u8 uuid[BTRFS_UUID_SIZE];
+
+	/* uuid of FS who owns this device */
+	__u8 fsid[BTRFS_UUID_SIZE];
+} __attribute__ ((__packed__));
+
+/*
+ * the super block basically lists the main trees of the FS
+ * it currently lacks any block count etc etc
+ */
+struct btrfs_super_block {
+	__u8 csum[BTRFS_CSUM_SIZE];
+	/* the first 3 fields must match struct btrfs_header */
+	__u8 fsid[BTRFS_FSID_SIZE];    /* FS specific uuid */
+	__u64 bytenr; /* this block number */
+	__u64 flags;
+
+	/* allowed to be different from the btrfs_header from here own down */
+	__u64 magic;
+	__u64 generation;
+	__u64 root;
+	__u64 chunk_root;
+	__u64 log_root;
+
+	/* this will help find the new super based on the log root */
+	__u64 log_root_transid;
+	__u64 total_bytes;
+	__u64 bytes_used;
+	__u64 root_dir_objectid;
+	__u64 num_devices;
+	__u32 sectorsize;
+	__u32 nodesize;
+	__u32 leafsize;
+	__u32 stripesize;
+	__u32 sys_chunk_array_size;
+	__u64 chunk_root_generation;
+	__u64 compat_flags;
+	__u64 compat_ro_flags;
+	__u64 incompat_flags;
+	__u16 csum_type;
+	__u8 root_level;
+	__u8 chunk_root_level;
+	__u8 log_root_level;
+	struct btrfs_dev_item dev_item;
+
+	char label[BTRFS_LABEL_SIZE];
+
+	/* future expansion */
+	__u64 reserved[32];
+	__u8 sys_chunk_array[BTRFS_SYSTEM_CHUNK_ARRAY_SIZE];
+} __attribute__ ((__packed__));
+
 /*
  * Byte swap functions
  */


             reply	other threads:[~2009-01-08 21:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08 21:08 Eric Sandeen [this message]
2009-01-20  5:58 ` [PATCH] blkid: recognize btrfs Theodore Tso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49666B40.2090106@redhat.com \
    --to=sandeen@redhat.com \
    --cc=CHRIS.MASON@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).