public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Emmanuel Colbus <ecolbus@manux.info>
Cc: 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 16:19:14 -0400	[thread overview]
Message-ID: <20140415201914.GK4456@thunk.org> (raw)
In-Reply-To: <534D5119.8050701@manux.info>

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...)

					- Ted

  parent reply	other threads:[~2014-04-15 20:19 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 [this message]
2014-04-15 20:58       ` Emmanuel Colbus

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=20140415201914.GK4456@thunk.org \
    --to=tytso@mit.edu \
    --cc=ecolbus@manux.info \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox