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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
