Hi, 

I've addressed the comments from Christoph, Steve, Dave, Shaggy and Eric.
The points are followings.

- Fixed unlockfs method in ext3/4, xfs, gfs2, jfs and reiserfs
  so that they always return 0 (success).
  Because the caller (thaw_bdev()) should unfreeze a filesystem
  successfully even in case of unlockfs's failure.

- Fixed xfs's write_super_lockfs so that it returns an error
  of xfs_trans_reserve() and xfs_trans_commit().

- Fixed gfs2's write_super_lockfs so that it returns -EINVAL

- Rename write_super_lockfs/unlockfs of the super block operation
  freeze_fs/unfreeze_fs to avoid a confusion.

Currently, ext3 in mainline Linux doesn't have the freeze feature which
suspends write requests.  So, we cannot take a backup which keeps
the filesystem's consistency with the storage device's features
(snapshot and replication) while it is mounted.
In many case, a commercial filesystem (e.g. VxFS) has
the freeze feature and it would be used to get the consistent backup.
If Linux's standard filesystem ext3 has the freeze feature, we can do it
without a commercial filesystem.

So I have implemented the ioctls of the freeze feature.
I think we can take the consistent backup with the following steps.
1. Freeze the filesystem with the freeze ioctl.
2. Separate the replication volume or create the snapshot
   with the storage device's feature.
3. Unfreeze the filesystem with the unfreeze ioctl.
4. Take the backup from the separated replication volume
   or the snapshot.

[PATCH 1/10] VFS: Fix error handling of write_super_lockfs/unlockfs
  Changed the type of write_super_lockfs and unlockfs from "void"
  to "int" so that they can return an error. 
  Rename write_super_lockfs/unlockfs of the super block operation
  freeze_fs/unfreeze_fs to avoid a confusion.

[PATCH 2/10]-[PATCH 6/10] Fix error handling in write_super_lockfs/unlockfs
                          (ext3, ext4, xfs, gfs2, jfs)
  Changed write_super_lockfs so that it returns an error if needed.
  unlockfs ...
[ message continues ]

Would it be a good idea to merge patch 10 into patch 8?   Otherwise, there's
two issues I can see:

1) A mostly theoretical problem if a bisect lands exactly on patch 9 it can
hit the deadlock.

2) The API at patch 8 and patch 10 differs, that's going to make testing through
a bisection of this patch series a pain.
[ message continues ]

Really, there's no deadlock until someone uses the new function, so
that's not really an issue, is it?  However, this patchset breaks
bisection anyway.

A bisect anywhere between patch 1 and 7 will cause some number of
filesystems to fail to compile.  Patches 1-7 either need to be combined
into one, or patch 1 needs to add freeze_fs and unfreeze_fs while
leaving write_super_lockfs and unlockfs, then a patch between 7 and 8

There's no need to test the new interface during a bisection.  Bisection
is important in testing regressions, but not new function.
-- 
David Kleikamp
IBM Linux Technology Center

--

[ message continues ]