From: Christoph Hellwig <hch@infradead.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] stat: don't fail if the major number is >= 256
Date: Mon, 11 Apr 2022 08:16:43 -0700 [thread overview]
Message-ID: <YlRGW43oXfss6Lfj@infradead.org> (raw)
In-Reply-To: <YlRDSXQG+ED1Okpp@casper.infradead.org>
On Mon, Apr 11, 2022 at 04:03:37PM +0100, Matthew Wilcox wrote:
> Is it better? You've done a good job arguing why it is for this particular
> situation, but if there's a program which compares files by
> st_dev+st_ino, it might think two files are identical when they're
> actually different and, eg, skip backing up a file because it thinks
> it already did it. That would be a silent failure, which is worse
> than this noisy failure.
Agreed.
> The real problem is clearly that Linus denied my request for a real
> major number for NVMe back in 2012 or whenever it was :-P
I don't think that is the real probem. The whole dynamic dev_t scheme
has worked out really well and I'm glade drivers don't need a major
allocation anymore. But I'm not sure why the dynamic major had to be
past 255 given these legacy issues, especially as there are plenty of
free ones with lower numbers.
next prev parent reply other threads:[~2022-04-11 15:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 14:43 [PATCH] stat: don't fail if the major number is >= 256 Mikulas Patocka
2022-04-11 15:03 ` Matthew Wilcox
2022-04-11 15:16 ` Christoph Hellwig [this message]
2022-04-11 16:30 ` Linus Torvalds
2022-04-11 17:13 ` Mikulas Patocka
2022-04-12 5:37 ` Linus Torvalds
2022-04-12 5:41 ` Christoph Hellwig
2022-04-12 5:47 ` Linus Torvalds
2022-04-12 5:52 ` Christoph Hellwig
2022-04-12 6:49 ` Linus Torvalds
2022-04-12 8:19 ` Andreas Schwab
2022-04-12 9:41 ` [PATCH] stat: fix inconsistency between struct stat and struct compat_stat Mikulas Patocka
2022-04-12 16:30 ` Linus Torvalds
2022-04-12 17:42 ` Mikulas Patocka
2022-04-12 23:25 ` Linus Torvalds
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=YlRGW43oXfss6Lfj@infradead.org \
--to=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.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