[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFEAcA9kktJd8EJ1VCp4a0XikPS9mxmag2GFv0NvwobubQLABw@mail.gmail.com>
Date: Tue, 21 Apr 2020 14:02:39 +0100
From: Peter Maydell <peter.maydell@...aro.org>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Florian Weimer <fw@...eb.enyo.de>,
Linus Walleij <linus.walleij@...aro.org>,
"Theodore Ts'o" <tytso@....edu>,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
QEMU Developers <qemu-devel@...gnu.org>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH] fcntl: Add 32bit filesystem mode
On Tue, 21 Apr 2020 at 00:51, Andreas Dilger <adilger@...ger.ca> wrote:
> Another question I had here is whether the filesystem needs to provide
> 32-bit values for other syscalls, such as stat() and statfs()? For
> ext4, stat() is not going to return a 64-bit inode number, but other
> filesystems might (e.g. Lustre has a mode to do this). Similarly,
> should statfs() scale up f_bsize until it can return a 32-bit f_blocks
> value? We also had to do this ages ago for Lustre when 32-bit clients
> couldn't handle > 16TB filesystems, but that is a single disk today.
>
> Should that be added into F_SET_FILE_32BIT_FS also?
Interesting question. The directory-offset is the thing that's
got peoples' attention because it's what has actually been hit
in real-world situations, but other syscalls have the same
potential problem too. The closest I can think of to a 'general
rule' (in terms of what QEMU would like) would be "behave the
same way you would for a compat32 syscall if you had one, or
how you would behave on an actual 32-bit host".
thanks
-- PMM
Powered by blists - more mailing lists