From: Emmanuel Colbus <ecolbus@manux.info>
To: "Theodore Ts'o" <tytso@mit.edu>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][5/11][MANUX] Kernel compatibility : major/minor numbers
Date: Tue, 15 Apr 2014 22:58:11 +0200 [thread overview]
Message-ID: <534D9D63.2050608@manux.info> (raw)
In-Reply-To: <20140415201914.GK4456@thunk.org>
Le 15/04/2014 22:19, Theodore Ts'o a écrit :
> On Tue, Apr 15, 2014 at 05:32:41PM +0200, Emmanuel Colbus wrote:
>>> In addition the
>>> standards and common sense together pretty much imply that you need each
>>> device to at least have a unique identifier.
>>>
>>
>> Why is it? I mean, as far as userspace is concerned, they do have a
>> unique identifier : their name. How would it be problematic that the
>> software is unable to confirm that /dev/null is actually connected to
>> the usual /dev/null kernel driver? I mean, it's supposed to trust the OS
>> and its admin to have done their job properly, not second-guess them!
>
> Backup programs will very often assume that if after two files, if
> stat(2)'ed, have the same st_ino and st_dev (which is a major/minor
> pair), then they are both hard links to the same underlying files.
>
> There are also programs that will relying on st_dev for the purpose of
> honoring find -xdev, and there are also programs that may try to do
> intelligent things by assuming that st_dev and st_ino togehter will
> uniquely name the same content. This gets tricky for remote file
> systems to get right, but file systems that don't at least try to get
> this right can end up triggering some very hard to debug userspace
> bugs. Transarc's Andrew File System (AFS) would occasionally break
> this property, back in the late 1990's, and it was the cause of Much
> Hilarity (except on the part of the programmers who had to figure out
> why certain programs were stuck looping forever while trying to
> analyze a long AFS pathname...)
Yes, in fact, I do respect the unicity of the st_dev field, so all these
assumptions work. The only thing I'm doing is violating the assumption
that, if a file has a certain major and minor numbers according to its
st_dev field, then there is a special block file in /dev that has the
same major and minor numbers and that corresponds to the storage
peripheral where this file is stored.
Emmanuel
prev parent reply other threads:[~2014-04-15 20:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 13:42 [RFC][5/11][MANUX] Kernel compatibility : major/minor numbers Emmanuel Colbus
2014-04-15 15:02 ` Austin S Hemmelgarn
2014-04-15 17:39 ` Emmanuel Colbus
2014-04-15 15:06 ` One Thousand Gnomes
2014-04-15 15:32 ` Emmanuel Colbus
2014-04-15 15:40 ` One Thousand Gnomes
2014-04-15 20:19 ` Theodore Ts'o
2014-04-15 20:58 ` Emmanuel Colbus [this message]
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=534D9D63.2050608@manux.info \
--to=ecolbus@manux.info \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--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 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.