[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac74bdb82e114d71b26864fe51f6433b@AcuMS.aculab.com>
Date: Fri, 15 Dec 2023 18:27:22 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'NeilBrown' <neilb@...e.de>, Al Viro <viro@...iv.linux.org.uk>
CC: Chuck Lever <chuck.lever@...cle.com>, Christian Brauner
<brauner@...nel.org>, Jens Axboe <axboe@...nel.dk>, Oleg Nesterov
<oleg@...hat.com>, Jeff Layton <jlayton@...nel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>
Subject: RE: [PATCH 1/3] nfsd: use __fput_sync() to avoid delayed closing of
files.
...
> > PS: put it that way - I can buy "nfsd is doing that only to regular
> > files and not on an arbitrary filesystem, at that; having the thread
> > wait on that sucker is not going to cause too much trouble"; I do *not*
> > buy turning it into a thing usable outside of a very narrow set of
> > circumstances.
> >
>
> Can you say more about "not on an arbitrary filesystem" ?
> I guess you means that procfs and/or sysfs might be problematic as may
> similar virtual filesystems (nfsd maybe).
Can nfs export an ext4 fs that is on a loopback mount on a file
that is remotely nfs (or other) mounted?
As soon as you get loops like that you might find that fput() starts
being problematic.
I'm also sure I remember that nfs wasn't supposed to respond to a write
until it had issued the actual disk write - but maybe no one do that
any more because it really is too slow.
(Especially if the 'disk' is a USB stick.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists