From: Al Viro <viro@ZenIV.linux.org.uk>
To: Gwendal Grignou <gwendal@google.com>
Cc: Daniel Ehrenberg <dehrenberg@google.com>,
linux-fsdevel@vger.kernel.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
Gwendal Grignou <gwendal@chromium.org>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Subject: Re: [RFC PATCH] vfs: Use 12:20 bit major:minor in stat everywhere
Date: Wed, 4 Mar 2015 01:47:32 +0000 [thread overview]
Message-ID: <20150304014731.GW29656@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAMHSBOXDT953g25uCvcALqCZskqF126SVOb2nbUQf1A_tJ=+Hg@mail.gmail.com>
On Tue, Mar 03, 2015 at 05:37:31PM -0800, Gwendal Grignou wrote:
> At least, to base the device format on whether we are running on a 32
> bit or 64 bit architecture does not make sense.
Yes, it does. Note that on 32bit ones stat64(2) *will* return an arbitrary
value. On 64bit ones stat(2) will.
> If a tool calling stat(2) can not handle 12 bit major/20 bits minor,
> it would already break or about to break when running on a 64 bit
> machine.
>
> Regarding SCSI, the 17th disk will use SCSI_DISK1_MAJOR (65). Only the
> 257th disk will use the first scsi major (8) again and need a minor
> greater than 256. (see sd_major() in drivers/scsi/sd.c for details).
*nod*
It's been years since I last looked at sd.c, TBH...
Said that, with NFS it's definitely a minor per superblock, and it's not the
only set_anon_super() user. Having a bunch of filesystems mounted over NFS
will suffice...
next prev parent reply other threads:[~2015-03-04 1:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 0:37 [RFC PATCH] vfs: Use 12:20 bit major:minor in stat everywhere Dan Ehrenberg
2015-03-04 0:53 ` Al Viro
2015-03-04 1:10 ` Daniel Ehrenberg
2015-03-04 1:22 ` Al Viro
2015-03-04 1:37 ` Gwendal Grignou
2015-03-04 1:47 ` Al Viro [this message]
2015-03-04 7:26 ` Gwendal Grignou
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=20150304014731.GW29656@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dehrenberg@google.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=gwendal@chromium.org \
--cc=gwendal@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 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.