Skip to contentSkip to conversation

review: don't block non-blocking writes when frozen

DISCUSSION David Chinner 2 participants 4 messages Apr 23, 2007 – Apr 24, 2007

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

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))
#1 lore raw
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)

#2 lore raw
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
#3 lore raw
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.