review: don't block non-blocking writes when frozen
Subsystems (3)
Prevent nfsds for blocking trying to write to a frozen filesystem or a filesystem in the process of freezing.
Cheers,
Dave.
Signature · 23 lines
Dave Chinner
Principal Engineer
SGI Australian Software Group
---
fs/xfs/linux-2.6/xfs_lrw.c | 4 ++++
1 file changed, 4 insertions(+)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_lrw.c
===================================================================
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-03-29 19:03:30.000000000 +1000
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_lrw.c 2007-03-29 19:08:06.262169809 +1000
@@ -684,6 +684,10 @@ xfs_write(
io = &xip->i_iocore;
mp = io->io_mount;
+ if (FILP_DELAY_FLAG(file) && vfs_test_for_freeze(vp->v_vfsp)) {
+ /* so nfsd can return EJUKEBOX to clients during a freeze */
+ return -EAGAIN;
+ }
vfs_wait_for_freeze(vp->v_vfsp, SB_FREEZE_WRITE);
if (XFS_FORCED_SHUTDOWN(mp))Quoted 3 lines · David Chinner
Prevent nfsds for blocking trying to write to a frozen filesystem or a filesystem in the process of freezing.
Looks good for trees actually having support for non-blocking file I/O, which doesn't include mainline. (So please don't send this upstead)
Quoted 8 lines · Christoph Hellwig
Quoted 3 lines · David Chinner
Prevent nfsds for blocking trying to write to a frozen filesystem or a filesystem in the process of freezing.
Looks good for trees actually having support for non-blocking file I/O, which doesn't include mainline. (So please don't send this upstead)
Yeah - you NACKed that a year ago based on the fact it would never get used by mainline code:
http://marc.info/?l=linux-nfs&m=114683005119982&w=2
So, given the catch-22 you've just presented us can we revisit the nfsd non-blocking I/O issue again? This affects anyone using DM snapshots on their NFS servers and has nothing to do with HSMs or DMAPI...
FWIW, you can still do non-blocking userspace I/O to a file, so this XFS patch is still valid for mainline (that's how I tested it).
Cheers,
Dave.
Signature · 3 lines
Dave Chinner Principal Engineer SGI Australian Software Group
Quoted 7 lines · David Chinner
So, given the catch-22 you've just presented us can we revisit the nfsd non-blocking I/O issue again? This affects anyone using DM snapshots on their NFS servers and has nothing to do with HSMs or DMAPI...
FWIW, you can still do non-blocking userspace I/O to a file, so this XFS patch is still valid for mainline (that's how I tested it).
I've been investigating the situation a little bit more, and here's what's going on:
- SuS allows for O_NONBLOCK on regular files as per
http://www.opengroup.org/onlinepubs/007908799/xsh/write.html
- actually implementing O_NONBLOCK semantics for regular fixes breaks userspace when poll/select claims files are ready to read/write but they aren't, see http://lkml.org/lkml/2004/10/17/17
So we can't really expose O_NONBLOCK on regular files to userspace, and we need to make sure in common code this does not happen.
EJUKEBOX on snaphots does make sense, though. Can you please send a full patchseries for nfsd, the common code and the xfs writepath so that this actually gets used and behaviour is consistant for all (or at least most) filesystems?
Also now that the patch goes to mainline please kill ugly FILP_DELAY_FLAG and just check the flags directly. And it should probably only check O_NONBLOCK. The only architecture having O_NDELAY different from O_NONBLOCK is sparc, and it already translates the value for us.