diff mbox

btrfs-progs: add mount status check for btrfs-image

Message ID 1404353196-10914-2-git-send-email-guihc.fnst@cn.fujitsu.com (mailing list archive)
State Superseded, archived
Headers show

Commit Message

Gui Hecheng July 3, 2014, 2:06 a.m. UTC
The btrfs-image tool should not be run on a mounted filesystem.
The undergoing fs operations may change what you have imaged a while ago,
this makes the image meanmingless.

Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
---
 btrfs-image.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

Comments

David Sterba July 3, 2014, 4:58 p.m. UTC | #1
On Thu, Jul 03, 2014 at 10:06:34AM +0800, Gui Hecheng wrote:
> The btrfs-image tool should not be run on a mounted filesystem.

Should not, but for some values of "sometimes" it makes sense, eg.
capturing image of an otherwise quiescent filesystem, a read-only mount
or after a crash.

This utility is used for debugging so I'd prefer to let the user do as
he likes, though printing the warning about the mount status is a good
improvement.

> The undergoing fs operations may change what you have imaged a while ago,
> this makes the image meanmingless.

I'm not familiar with the image format, but maybe we can set a bit in
the header when the filesystem was not captured cleanly.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gui Hecheng July 4, 2014, 1:57 a.m. UTC | #2
On Thu, 2014-07-03 at 18:58 +0200, David Sterba wrote:
> On Thu, Jul 03, 2014 at 10:06:34AM +0800, Gui Hecheng wrote:
> > The btrfs-image tool should not be run on a mounted filesystem.
> 
> Should not, but for some values of "sometimes" it makes sense, eg.
> capturing image of an otherwise quiescent filesystem, a read-only mount
> or after a crash.

Ah, read-only mount is really a case.

> This utility is used for debugging so I'd prefer to let the user do as
> he likes, though printing the warning about the mount status is a good
> improvement.

I agree, then I'll keep the check_mounted and just give a prompt and let
it continue.

> > The undergoing fs operations may change what you have imaged a while ago,
> > this makes the image meanmingless.
> 
> I'm not familiar with the image format, but maybe we can set a bit in
> the header when the filesystem was not captured cleanly.

Hmm...This is a point, I think I'll give it a try in another patch.


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/btrfs-image.c b/btrfs-image.c
index 985aa26..9719d1c 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -2570,10 +2570,20 @@  int main(int argc, char *argv[])
 			num_threads = 1;
 	}
 
-	if (create)
+	if (create) {
+		ret = check_mounted(source);
+		if (ret < 0) {
+			fprintf(stderr, "Could not check mount status: %s\n",
+			strerror(-ret));
+			exit(1);
+		} else if (ret) {
+			fprintf(stderr, "The device is busy\n");
+			exit(1);
+		}
+
 		ret = create_metadump(source, out, num_threads,
 				      compress_level, sanitize, walk_trees);
-	else
+	} else
 		ret = restore_metadump(source, out, old_restore, 1,
 				       multi_devices);
 	if (ret) {