linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: "Ricardo M. Correia" <Ricardo.M.Correia@sun.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	linux-ext4@vger.kernel.org, Karel Zak <kzak@redhat.com>
Subject: Re: [PATCH e2fsprogs] Add ZFS detection to libblkid
Date: Sat, 04 Apr 2009 15:25:07 -0600	[thread overview]
Message-ID: <20090404212507.GC3199@webber.adilger.int> (raw)
In-Reply-To: <49D75AD1.7060101@redhat.com>

On Apr 04, 2009  08:04 -0500, Eric Sandeen wrote:
> And from another report, another user's zfs partition:
> 
> # hexdump -C first_400K | grep "0c b1 07 b0 f5 02 00 00"
> # hexdump -C first_400K | grep "00 00 02 f5 b0 07 b1 0c"
> # hexdump -C first_400K | grep "0c b1 ba 00"
> 00015e30  30 e8 ff ff 85 c0 5b 75  48 8b 06 35 0c b1 ba 00
> 
> Should we be looking for 0x00babloc at offset 00015e30?

In probe.c I see the magic (that I've been assuming is correct, because
it isn't really that easy to read):

  { "zfs",       8,      0,  8, "\0\0\x02\xf5\xb0\x07\xb1\x0c", probe_zfs },
  { "zfs",       8,      0,  8, "\x0c\xb1\x07\xb0\xf5\x02\0\0", probe_zfs },
  { "zfs",     264,      0,  8, "\0\0\x02\xf5\xb0\x07\xb1\x0c", probe_zfs },
  { "zfs",     264,      0,  8, "\x0c\xb1\x07\xb0\xf5\x02\0\0", probe_zfs },

but looking at this I have no idea what this magic value is supposed
to represent, from reading the ondiskformat0822.pdf (ZFS spec) document.

According to that the __u64 ub_magic is supposed to be 0x0000000000bab10c
(big endian) or 0x0xb1ba0000000000 (little endian), at 128kB offset, and
128*1kB thereafter (assuming the filesystem has been used enough to
write 128 transactions).  This should repeat again at 256kB + 128kB.

In the zfs.img.bz2 that I have (and sent Karel recently for util-linux-ng)
I don't see the ub_magic at the right offset.  The NVpair data IS
in the right 16kB offset, and contains all of the expected data (version,
name, pool_guid, etc) so it isn't just an issue of the device having the
wrong offset.  The ub_magic is at 0x21000, 0x21400, ..., and for the
second überblock at 0x61000, 0x61400, so this is off by 0x1000 or 16kB.

I _suppose_ there is no hard requirement that the ub_magic is present in
the first überblock slot at 128kB, but that does make it harder to find.
In theory we would need to add 256 magic value checks, which seems
unreasonable.  Ricardo, do you know why the zfs.img.bz2 has bad überblocks
for the first 4 slots?



In any case, the ZFS magic above is completely broken and needs fixing,
as does the patch I sent Karel for util-linux-ng.  For e2fsprogs it seems
it should be something like the following:

  { "zfs",     128,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     128,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     132,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     132,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     136,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     136,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     384,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     384,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     388,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     388,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },
  { "zfs",     392,      0,  8, "\0\0\0\0\0\xba\xb1\xc",probe_zfs },
  { "zfs",     392,      0,  8, "\xc\xb1\xba\0\0\0\0\0",probe_zfs },

and for util-linux-ng it should be like the following:

               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 128, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 128, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 132, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 132, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 136, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 136, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 384, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 384, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 388, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 388, .sboff = 0 },
               { .magic = "\0\0\0\0\0\xba\xb1\xc", .len = 8,
                 .kboff = 392, .sboff = 0 },
               { .magic = "\xc\xb1\xba\0\0\0\0\0", .len = 8,
                 .kboff = 392, .sboff = 0 },


Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-04-04 21:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-30 18:20 [PATCH e2fsprogs] Add ZFS detection to libblkid Ricardo M. Correia
2008-06-02  7:41 ` Karel Zak
2008-06-02 15:03   ` Ricardo M. Correia
     [not found]   ` <1212418863.7337.34.camel@localhost>
2008-06-02 20:58     ` Karel Zak
2008-06-02 21:38       ` Andreas Dilger
2008-06-02 22:31         ` Karel Zak
2008-06-02 23:11           ` Andreas Dilger
2008-06-03  0:05       ` Theodore Tso
2008-06-03  1:11 ` Theodore Tso
2009-04-04  2:39 ` Eric Sandeen
2009-04-04 13:04   ` Eric Sandeen
2009-04-04 21:25     ` Andreas Dilger [this message]
2009-04-04 21:46       ` Eric Sandeen
2009-04-06  6:25         ` Andreas Dilger
2009-04-06 19:22       ` Ricardo M. Correia
2009-04-06 20:13         ` Eric Sandeen
2009-04-13 19:18           ` Ricardo M. Correia
2009-04-13 19:27             ` Eric Sandeen
2009-04-06 20:35         ` Karel Zak
2009-04-07  7:40         ` Andreas Dilger
2009-04-13 19:29           ` Ricardo M. Correia
2009-04-17  9:51             ` Karel Zak

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=20090404212507.GC3199@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=Ricardo.M.Correia@sun.com \
    --cc=kzak@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /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).