Good point. Please see attached patch. It allows to control whether the DataTransfer device (through which the initiators access the snapshots) should be read-write or read-only Yes, now that we have a really nice and very useful enterprise feature some writeup and pretty pictures of using it would be good. Let me see what I can come up with over the next few weeks or so. regards ronnie sahlberg On Sun, Jan 29, 2012 at 7:54 AM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Sat, 28 Jan 2012 14:28:41 +1100 > Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > >> 1, This allows creating a SBC device without any backing store. I.e. no media loaded yet. >> It automatially forces such devices to be removable==1 and online==0 (no media loaded) >> >> 2, Add a new option to SMC so that you can force a storage elemet slot to become Empty. >> >> 3, Now, This is the funky stuff this has all been leading up to: >> Add documentation/script to create a SBC jukebox. >> This jukebox (when used ontop of BTRFS) can take snapshots of a different file >> (a file used to be exported as a normal SBC LUN thought a different target) >> that file can be snapshotted regularely via a cronjob. >> All x most recent snbapshots are then exported via a dedicated snapshot-target when an >> initiator can attach, pich which nsnapshot it wants to use (using MTX) and then access >> the content of the snapshot. >> >> i.e. >> You export a SBC LUN to an initiator. >> Then you use this snapshot script to create regular snapshots of that SBC device. >> These snapshots are then exported with a mediachanger through a different target to different initiators. >> Those other initiators can now access these point in time snapshots of the production LUN. > > Shapshots are exported in read-only mode, right? > > Anyway, the feature sounds really cool. You should talk about it at > a conference or post an article at a popular web site :) > > Merged, thanks a lot! >
Attachment:
0001-SBC-Jukebox-Allow-the-snapshots-to-be-read-only-or-r.patch.gz
Description: GNU Zip compressed data
From 827addd0ce950e9ab7b852ea4a043e6d06cbe0c7 Mon Sep 17 00:00:00 2001
From: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>
Date: Sun, 29 Jan 2012 16:57:41 +1100
Subject: [PATCH] SBC Jukebox: Allow the snapshots to be read-only or read-write
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>
---
doc/README.sbcjukebox | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/doc/README.sbcjukebox b/doc/README.sbcjukebox
index 87bf73c..2e21705 100755
--- a/doc/README.sbcjukebox
+++ b/doc/README.sbcjukebox
@@ -17,6 +17,7 @@
# SNAPDIR is where we keep the SMC media file as well as where all snapshots are
# kept. This must be the same filesystem as FILE
# NUMSLOTS is how many old snapshots we want to keep.
+# READONLYSNAPS is whether or not the snapshot device is readonly or not
# sbcjukebox.sh start
# to create the target and populate the storage elements.
@@ -35,7 +36,7 @@ TNAME="iqn.ronnie.test-snapshot"
FILE="/data/RHEL6/RHEL6-1.img"
SNAPDIR="${FILE}.snapshots"
NUMSLOTS=8
-
+READONLYSNAPS="yes"
[ -d "$SNAPDIR" ] || mkdir "$SNAPDIR"
@@ -91,6 +92,10 @@ start() {
tgtadm --op new --mode logicalunit --tid $TID --lun 1 -Y disk
tgtadm --op update --mode logicalunit --tid $TID --lun 1 --params vendor_id=STGT,product_id=SNAPSHOT_SBC,product_rev=0010
+ [ "$READONLYSNAPS" != "yes" ] || {
+ tgtadm --op update --mode logicalunit --tid $TID --lun 1 --params readonly=1
+ }
+
# create backing store for SMC
[ -f "${SNAPDIR}/smc" ] || dd if=/dev/zero of="${SNAPDIR}/smc" bs=1k count=1
--
1.7.3.1
