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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox