zfs discuss - Feb 2006 - zfs mirror as a backup mechanism

How well or bad would zfs be, used in the following configuration? I have a
laptop, and I want to be able to use it normally. But I would also like to have
backups either when I have access to the network or when I plug-in the right
usb-storage. I could use rsync, but I was thinking of having my home filesystem
on a zpool that would be a mirror of a partition of the laptop and the usb disk
(or something mounted by nfs), and count on the filesystem for the
synchronisation. Is zfs well suited for this? (is it scared when it sees two
disks so out of sync, does the synchronisation make the disk unusable for some
time, etc)
This message posted from opensolaris.org

I have no idea how well zfs would handle this but still it doesn''t
sound like a good idea.  A mirror is for redundancy and not for backup. When you
have the mirror online and remove the wrong file by accident what will you do?
This message posted from opensolaris.org

On 22 Feb 2006, at 10:58, Stefan Johansson wrote:
> I have no idea how well zfs would handle this but still it doesn''t
> sound like a good idea.  A mirror is for redundancy and not for  
> backup. When you have the mirror online and remove the wrong file  
> by accident what will you do?
Ok, mirror + snapshots then?

The only disadvantage I can see is that it will mirror all the  
changed blocks, not just the ones that you are using right now.

So granted that the mirroring works as it should work, and doesn''t  
panic, there will just be a whole lot more data to mirror. I think.

Wout.

Wout Mertens wrote:
> On 22 Feb 2006, at 10:58, Stefan Johansson wrote:
> 
>> I have no idea how well zfs would handle this but still it
doesn''t
>> sound like a good idea.  A mirror is for redundancy and not for 
>> backup. When you have the mirror online and remove the wrong file by 
>> accident what will you do?
> 
> Ok, mirror + snapshots then?
> 
> The only disadvantage I can see is that it will mirror all the changed 
> blocks, not just the ones that you are using right now.
> 
> So granted that the mirroring works as it should work, and doesn''t
> panic, there will just be a whole lot more data to mirror. I think.
But there will be considerably less data to resilver onto the
less frequently attached side of the mirror than if you were
using SVM. This is because unlike UFS+SVM ZFS actually knows
what data on the disk is data and ZFS metadata rather than just
making both sides bitwise the same.

-- 
Darren J Moffat

On 22 Feb 2006, at 12:48, Darren J Moffat wrote:
> Wout Mertens wrote:
>> On 22 Feb 2006, at 10:58, Stefan Johansson wrote:
>>> I have no idea how well zfs would handle this but still it  
>>> doesn''t sound like a good idea.  A mirror is for
redundancy and
>>> not for backup. When you have the mirror online and remove the  
>>> wrong file by accident what will you do?
>> Ok, mirror + snapshots then?
>> The only disadvantage I can see is that it will mirror all the  
>> changed blocks, not just the ones that you are using right now.
>> So granted that the mirroring works as it should work, and
doesn''t
>> panic, there will just be a whole lot more data to mirror. I think.
>
> But there will be considerably less data to resilver onto the
> less frequently attached side of the mirror than if you were
> using SVM. This is because unlike UFS+SVM ZFS actually knows
> what data on the disk is data and ZFS metadata rather than just
> making both sides bitwise the same.
Actually, this is starting to sound like a really good idea. Can this  
really work?

I''m envisioning an external disk to a laptop, and every once in a  
while you plug it in. Hotplug scripts notice it and start the  
resilver. If you have to go, just unplug the disk, the data will be ok.

Yesno?

Wout.

> How well or bad would zfs be, used in the following
> configuration? I have a laptop, and I want to be able
> to use it normally. But I would also like to have
> backups either when I have access to the network or
> when I plug-in the right usb-storage.
There''s a small technical problem at this time: using both zfs and usb
mass storage at the same time doesn''t work too well, because zfs is
using lots of kernel memory and the Solaris usb hcd drivers on the
x86 platform do not work well in this situation.  See bug 6372009:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6372009

A Firewire HDD doesn''t have this problem.

For USB, you can also try the workaround from bug 6372009. I havn''t
tried
the workaround, but it might work. Probably kills usb mass storage
performance.
This message posted from opensolaris.org

A simpler situation. I have a fast disk and a slow disk. I would like to be able
to use the fast disk at (almost) full speed, and have the slow one try to catch
up as well as it can. Can a zfs mirror handle that? Or is there some other way
to achieve the same?
This message posted from opensolaris.org

Quoth Wout Mertens on Wed, Feb 22, 2006 at 02:26:34PM
+0100:
> Actually, this is starting to sound like a really good idea. Can this  
> really work?
> 
> I''m envisioning an external disk to a laptop, and every once in a
> while you plug it in. Hotplug scripts notice it and start the  
> resilver. If you have to go, just unplug the disk, the data will be ok.
Yes.  This is exactly what I do, except for automatic resilvering.  The
things you have to watch out for:

  - If the drive is cheap (like mine: Emprex MicroStorage 2.2GB), then
    you will probably have to set

	reduced-cmd-support=true

    for it in /kernel/drv/scsa2usb.conf to get it to work at all.  (See
    scsa2usb(7D).)

  - To allow ZFS to use the drive, you have to make the system think
    it''s not removable.  See

	http://blogs.sun.com/roller/page/artem?entry=zfs_on_the_go

  - Once you''ve created the mirror, be sure not to "zfs
detach" the
    drive from it.  If you do, and the local disk slice is larger than
    the USB slice, then you will not be able to reattach it.  Use "zfs
    offline" instead, or just yank it out (ZFS will mark the pool as
    degraded, but it will still work fine).

  - When I boot with the USB drive attached, it usually goes into
    conniptions and boot stops.  Pulling the drive allows boot to
    continue.  So I usually just boot without the drive, and then run
    "zfs online home c2t0d0p0" after the system comes up and
I''ve
    plugged the drive in.  I suspect for some reason at boot we''re
    sending one of the SCSI commands that "reduced-cmd-support" is
    supposed to stop, but I haven''t gotten around to debugging it yet.

  - Rarely my drive goes into spasms anyway (I think under heavier
    load), but pulling it out and plugging it back in later solves that.


David

> - To allow ZFS to use the drive, you have to make the system think
>     it''s not removable.  See
> 
> 	http://blogs.sun.com/roller/page/artem?entry=zfs_on_the_go
What exactly is the reason for this?  I''ve been using zpools on a usb
hdd
without forcing removable=false.

> - Rarely my drive goes into spasms anyway (I think under heavier
> load), but pulling it out and plugging it back in later solves that.
Doesn''t that panic the kernel, when zfs receives I/O errors, due to the
hot-removed active device?
This message posted from opensolaris.org

Quoth J?rgen Keil on Thu, Feb 23, 2006 at 03:50:32AM
-0800:
> > - To allow ZFS to use the drive, you have to make the system think
> >     it''s not removable.  See
> > 
> > 	http://blogs.sun.com/roller/page/artem?entry=zfs_on_the_go
> 
> What exactly is the reason for this?  I''ve been using zpools on a
usb hdd
> without forcing removable=false.
I don''t recall whether I tried it without removable=false.  I probably
just took Artem''s word for it.
> > - Rarely my drive goes into spasms anyway (I think under heavier
> > load), but pulling it out and plugging it back in later solves that.
> 
> Doesn''t that panic the kernel, when zfs receives I/O errors, due
to the
> hot-removed active device?
No.  I think you''re thinking of irreparable checksum failures, of which
I''ve encountered none.  (I think ZFS often reports errors from the USB
drive, but since it''s mirrored, the pool survives.)


David

> Quoth J?rgen Keil on Thu, Feb 23, 2006 at 03:50:32AM
> -0800:
> > > - To allow ZFS to use the drive, you have to make the system
think
> > >     it''s not removable.  See
> > > 
> > >   	http://blogs.sun.com/roller/page/artem?entry=zfs_on_the_go
> > 
> > What exactly is the reason for this?  I''ve been using zpools
on a usb hdd
> > without forcing removable=false.
> 
> I don''t recall whether I tried it without removable=false.  I
probably
> just took Artem''s word for it.
It seems there is already a bug filed for this:

Bug ID: 4953396
Synopsis: zfs should support removable media
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4953396

There''s not much visible description text in the bug report on
bugs.opensolaris.org.  Maybe the bug is about integration with vold,
so that we don''t have to stop vold / the volfs service for using 
removable media with zfs?
> > > - Rarely my drive goes into spasms anyway (I think under heavier
> > > load), but pulling it out and plugging it back in later solves
that.
> > 
> > Doesn''t that panic the kernel, when zfs receives I/O errors,
due to the
> > hot-removed active device?
> 
> No.  I think you''re thinking of irreparable checksum failures, of
which
> I''ve encountered none.  (I think ZFS often reports errors from the
USB
> drive, but since it''s mirrored, the pool survives.)
Nope, I/O errrors, like the one mention in bug 6372009:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6372009

panic[cpu0]/thread=ccf0ede0: ZFS: I/O failure (write on /dev/dsk/c4t0d0p0 off
5859e800: zio 9b44240 [L0 unallocated] vdev=0 offset=5819e800
size=1000L/c00P/c00A fletcher2 lzjb LE contiguous birth=66 fill=0
cksum=e5df659b9ece4544:9d661997c3cc1026:9fa3633b5e58de81:3753938f5e3d4327):
error 6


But that was on unmirrored zpools.
This message posted from opensolaris.org

Actually, there are potential problems either way:

With removable=true, you can hit problems with EFI (e.g. zpool create may fail
with "failed to write EFI label");
With removable=false, some commands might upset the USB disks;

There are multiple issues with ZFS on removable media, in USB, sd and ZFS, and
they''re being worked on. 6348407 will appear in b35, 6372009 should
also be fixed in b35 (thanks, Juergen!), some ZFS fixes I believe go in 35 or
36.

-Artem.
This message posted from opensolaris.org