All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: alessandro.suardi@oracle.com, jgarzik@mandrakesoft.com
Cc: andries.brouwer@cwi.nl, linux-kernel@vger.kernel.org,
	torvalds@transmeta.com
Subject: Re: 2.5.2-pre7 still missing bits of kdev_t
Date: Fri, 4 Jan 2002 01:47:52 GMT	[thread overview]
Message-ID: <UTC200201040147.BAA211896.aeb@cwi.nl> (raw)

    From jgarzik@mandrakesoft.com Fri Jan  4 01:13:34 2002

    reiserfs is blindly storing the kernel's kdev_t value raw to disk.

    AFAICS this will need a policy decision not just cleanup, before it
    works in 2.5.2 properly.  If we switch the kernel to 12:20 major:minor
    numbers, suddenly the reiserfs disk format changes based on kernel
    version, and earlier kernels see corrupted major:minor numbers.

No, not really. For how to do this, see a fragment of example code
that Linus removed from kdev_t.h in pre6, it went something like
(adapted for 12+20 instead of 16+16):

int major(dev_t dev) {
	int ma;

	ma = (dev >> 20);
	if (!ma)
		ma = (dev >> 8);
	return ma;
}

int minor(dev_t dev) {
	if (dev >> 20)
		return (dev & 0xfffff);
	else
		return (dev & 0xff);
}

dev_t mkdev(int ma, int mi) {
	if (mi & ~0xff)
		return ((ma << 20) + mi);
	else
		return ((ma << 8) + mi);
}

(with the correctness conditions that ma is 12-bit,
mi is 20-bit, and major 0 has only 8-bit minors).

You see that the representation of old values does not change.
No disk corruption.

Andries


[I didnt spell it out, but you understand: the dev_t is the on-disk
format, the conversion finds the major and minor, and these are
combined again into a kdev_t for use by the kernel]

[Similar code occurs is isofs/rock.c, where a 64-bit dev
must be converted.]

[I don't know whether reiserfs is a Linux-only filesystem.
If it is not, and has a disk format that is OS-independent,
a third struct stat_data might be needed, since the 12+20
is not universal, so 32+32 would be the better choice.]

             reply	other threads:[~2002-01-04  1:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-04  1:47 Andries.Brouwer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-01-04 19:32 2.5.2-pre7 still missing bits of kdev_t Andries.Brouwer
2002-01-04 19:24 Andries.Brouwer
2002-01-04 21:10 ` Alexander Viro
2002-01-04 21:14   ` Linus Torvalds
2002-01-05  0:10     ` Alan Cox
2002-01-04 13:21 Andries.Brouwer
2002-01-04  0:05 Alessandro Suardi
2002-01-04  0:13 ` Jeff Garzik
2002-01-04  2:32   ` Linus Torvalds
2002-01-04  6:52     ` Jeff Garzik
2002-01-04 16:45       ` Linus Torvalds
2002-01-04 17:34         ` Nikita Danilov
2002-01-04 17:51           ` Jeff Garzik
2002-01-04 17:53             ` Linus Torvalds
2002-01-04 18:11               ` Alexander Viro

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=UTC200201040147.BAA211896.aeb@cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=alessandro.suardi@oracle.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.