Send zfs-discuss mailing list submissions to
zfs-discuss@opensolaris.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
or, via email, send a message with subject or body 'help' to
zfs-discuss-requ...@opensolaris.org
You can reach the person managing the list at
zfs-discuss-ow...@opensolaris.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of zfs-discuss digest..."
Today's Topics:
1. Re: ZFS bug - should I be worried about this? (Gabriele Bulfon)
2. Re: ZFS bug - should I be worried about this? (Victor Latushkin)
3. Re: OCZ Vertex 2 Pro performance numbers (Frank Cusack)
4. Re: ZFS bug - should I be worried about this? (Garrett D'Amore)
5. Announce: zfsdump (Tristram Scott)
6. Re: Announce: zfsdump (Brian Kolaci)
7. Re: zpool import hangs indefinitely (retry post in parts; too
long?) (Andrew Jones)
8. Re: Announce: zfsdump (Tristram Scott)
9. Re: Announce: zfsdump (Brian Kolaci)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Jun 2010 05:16:00 PDT
From: Gabriele Bulfon <gbul...@sonicle.com>
To: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] ZFS bug - should I be worried about this?
Message-ID: <593812734.121277727391600.javamail.tweb...@sf-app1>
Content-Type: text/plain; charset=UTF-8
Yes...they're still running...but being aware that a power failure causing an
unexpected poweroff may make the pool unreadable is a pain....
Yes. Patches should be available.
Or adoption may be lowering a lot...
--
This message posted from opensolaris.org
------------------------------
Message: 2
Date: Mon, 28 Jun 2010 18:14:12 +0400
From: Victor Latushkin <victor.latush...@sun.com>
To: Gabriele Bulfon <gbul...@sonicle.com>
Cc: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] ZFS bug - should I be worried about this?
Message-ID: <4c28ae34.1030...@sun.com>
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
On 28.06.10 16:16, Gabriele Bulfon wrote:
Yes...they're still running...but being aware that a power failure causing an
unexpected poweroff may make the pool unreadable is a pain....
Pool integrity is not affected by this issue.
------------------------------
Message: 3
Date: Mon, 28 Jun 2010 07:26:45 -0700
From: Frank Cusack <frank+lists/z...@linetwo.net>
To: 'OpenSolaris ZFS discuss' <zfs-discuss@opensolaris.org>
Subject: Re: [zfs-discuss] OCZ Vertex 2 Pro performance numbers
Message-ID: <5f1b59775f3ffc0e1781f...@cusack.local>
Content-Type: text/plain; charset=us-ascii; format=flowed
On 6/26/10 9:47 AM -0400 David Magda wrote:
Crickey. Who's the genius who thinks of these URLs?
SEOs
------------------------------
Message: 4
Date: Mon, 28 Jun 2010 08:17:21 -0700
From: "Garrett D'Amore" <garr...@nexenta.com>
To: Gabriele Bulfon <gbul...@sonicle.com>
Cc: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] ZFS bug - should I be worried about this?
Message-ID: <1277738241.5596.4325.ca...@velocity>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2010-06-28 at 05:16 -0700, Gabriele Bulfon wrote:
Yes...they're still running...but being aware that a power failure causing an
unexpected poweroff may make the pool unreadable is a pain....
Yes. Patches should be available.
Or adoption may be lowering a lot...
I don't have access to the information, but if this problem is the same
one I think it is, then the pool does not become unreadable. Rather,
its state after such an event represents a *consistent* state from some
point of time *earlier* than that confirmed fsync() (or a write on a
file opened with O_SYNC or O_DSYNC).
For most users, this is not a critical failing. For users using
databases or requiring transactional integrity for data stored on ZFS,
then yes, this is a very nasty problem indeed.
I suspect that this is the problem I reported earlier in my blog
(http://gdamore.blogspot.com) about certain kernels having O_SYNC and
O_DSYNC problems. I can't confirm this though, because I don't have
access to the SunSolve database to read the report.
(This is something I'll have to check into fixing... it seems like my
employer ought to have access to that information...)
- Garrett
------------------------------
Message: 5
Date: Mon, 28 Jun 2010 08:26:02 PDT
From: Tristram Scott <tristram.sc...@quantmodels.co.uk>
To: zfs-discuss@opensolaris.org
Subject: [zfs-discuss] Announce: zfsdump
Message-ID: <311835455.361277738793747.javamail.tweb...@sf-app1>
Content-Type: text/plain; charset=UTF-8
For quite some time I have been using zfs send -R fsn...@snapname | dd
of=/dev/rmt/1ln to make a tape backup of my zfs file system. A few weeks back
the size of the file system grew to larger than would fit on a single DAT72
tape, and I once again searched for a simple solution to allow dumping of a zfs
file system to multiple tapes. Once again I was disappointed...
I expect there are plenty of other ways this could have been handled, but none
leapt out at me. I didn't want to pay large sums of cash for a commercial
backup product, and I didn't see that Amanda would be an easy thing to fit into
my existing scripts. In particular, (and I could well be reading this
incorrectly) it seems that the commercial products, Amanda, star, all are
dumping the zfs file system file by file (with or without ACLs). I found none
which would allow me to dump the file system and its snapshots, unless I used
zfs send to a scratch disk, and dumped to tape from there. But, of course,
that assumes I have a scratch disk large enough.
So, I have implemented zfsdump as a ksh script. The method is as follows:
1. Make a bunch of fifos.
2. Pipe the stream from zfs send to split, with split writing to the fifos (in
sequence).
3. Use dd to copy from the fifos to tape(s).
When the first tape is complete, zfsdump returns. One then calls it again,
specifying that the second tape is to be used, and so on.
From the man page:
Example 1. Dump the @Tues snapshot of the tank filesystem
to the non-rewinding, non-compressing tape, with a 36GB
capacity:
zfsdump -z t...@tues -a "-R" -f /dev/rmt/1ln -s 36864 -t 0
For the second tape:
zfsdump -z t...@tues -a "-R" -f /dev/rmt/1ln -s 36864 -t 1
If you would like to try it out, download the package from:
http://www.quantmodels.co.uk/zfsdump/
I have packaged it up, so do the usual pkgadd stuff to install.
Please, though, [b]try this out with caution[/b]. Build a few test file
systems, and see that it works for you.
[b]It comes without warranty of any kind.[/b]
Tristram
--
This message posted from opensolaris.org
------------------------------
Message: 6
Date: Mon, 28 Jun 2010 11:51:07 -0400
From: Brian Kolaci <brian.kol...@sun.com>
To: Tristram Scott <tristram.sc...@quantmodels.co.uk>
Cc: ZFS Discussions <zfs-discuss@opensolaris.org>
Subject: Re: [zfs-discuss] Announce: zfsdump
Message-ID: <4c28c4eb.2010...@sun.com>
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
I use Bacula which works very well (much better than Amanda did).
You may be able to customize it to do direct zfs send/receive, however I find
that although they are great for copying file systems to other machines, they
are inadequate for backups unless you always intend to restore the whole file
system. Most people want to restore a file or directory tree of files, not a
whole file system. In the past 25 years of backups and restores, I've never
had to restore a whole file system. I get requests for a few files, or
somebody's mailbox or somebody's http document root.
You can directly install it from CSW (or blastwave).
On 6/28/2010 11:26 AM, Tristram Scott wrote:
For quite some time I have been using zfs send -R fsn...@snapname | dd
of=/dev/rmt/1ln to make a tape backup of my zfs file system. A few weeks back
the size of the file system grew to larger than would fit on a single DAT72
tape, and I once again searched for a simple solution to allow dumping of a zfs
file system to multiple tapes. Once again I was disappointed...
I expect there are plenty of other ways this could have been handled, but none
leapt out at me. I didn't want to pay large sums of cash for a commercial
backup product, and I didn't see that Amanda would be an easy thing to fit into
my existing scripts. In particular, (and I could well be reading this
incorrectly) it seems that the commercial products, Amanda, star, all are
dumping the zfs file system file by file (with or without ACLs). I found none
which would allow me to dump the file system and its snapshots, unless I used
zfs send to a scratch disk, and dumped to tape from there. But, of course,
that assumes I have a scratch disk large enough.
So, I have implemented zfsdump as a ksh script. The method is as follows:
1. Make a bunch of fifos.
2. Pipe the stream from zfs send to split, with split writing to the fifos (in
sequence).
3. Use dd to copy from the fifos to tape(s).
When the first tape is complete, zfsdump returns. One then calls it again,
specifying that the second tape is to be used, and so on.
From the man page:
Example 1. Dump the @Tues snapshot of the tank filesystem
to the non-rewinding, non-compressing tape, with a 36GB
capacity:
zfsdump -z t...@tues -a "-R" -f /dev/rmt/1ln -s 36864 -t 0
For the second tape:
zfsdump -z t...@tues -a "-R" -f /dev/rmt/1ln -s 36864 -t 1
If you would like to try it out, download the package from:
http://www.quantmodels.co.uk/zfsdump/
I have packaged it up, so do the usual pkgadd stuff to install.
Please, though, [b]try this out with caution[/b]. Build a few test file
systems, and see that it works for you.
[b]It comes without warranty of any kind.[/b]
Tristram
------------------------------
Message: 7
Date: Mon, 28 Jun 2010 08:59:21 PDT
From: Andrew Jones <andrewnjo...@gmail.com>
To: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] zpool import hangs indefinitely (retry post
in parts; too long?)
Message-ID: <185781013.401277740792036.javamail.tweb...@sf-app1>
Content-Type: text/plain; charset=UTF-8
Now at 36 hours since zdb process start and:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
827 root 4936M 4931M sleep 59 0 0:50:47 0.2% zdb/209
Idling at 0.2% processor for nearly the past 24 hours... feels very stuck.
Thoughts on how to determine where and why?
--
This message posted from opensolaris.org
------------------------------
Message: 8
Date: Mon, 28 Jun 2010 09:26:12 PDT
From: Tristram Scott <tristram.sc...@quantmodels.co.uk>
To: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] Announce: zfsdump
Message-ID: <1916741256.441277742403278.javamail.tweb...@sf-app1>
Content-Type: text/plain; charset=UTF-8
I use Bacula which works very well (much better than
Amanda did).
You may be able to customize it to do direct zfs
send/receive, however I find that although they are
great for copying file systems to other machines,
they are inadequate for backups unless you always
intend to restore the whole file system. Most people
want to restore a file or directory tree of files,
not a whole file system. In the past 25 years of
backups and restores, I've never had to restore a
whole file system. I get requests for a few files,
or somebody's mailbox or somebody's http document
root.
You can directly install it from CSW (or blastwave).
Thanks for your comments, Brian. I should look at Bacula in more detail.
As for full restore versus ad hoc requests for files I just deleted, my
experience is mostly similar to yours, although I have had need for full system
restore more than once.
For the restore of a few files here and there, I believe this is now well
handled with zfs snapshots. I have always found these requests to be down to
human actions. The need for full system restore has (almost) always been
hardware failure.
If the file was there an hour ago, or yesterday, or last week, or last month,
then we have it in a snapshot.
If the disk died horribly during a power outage (grrr!) then it would be very
nice to be able to restore not only the full file system, but also the
snapshots too. The only way I know of achieving that is by using zfs send etc.
On 6/28/2010 11:26 AM, Tristram Scott wrote:
[snip]
Tristram
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discu
ss
--
This message posted from opensolaris.org
------------------------------
Message: 9
Date: Mon, 28 Jun 2010 13:00:06 -0400
From: Brian Kolaci <brian.kol...@sun.com>
To: Tristram Scott <tristram.sc...@quantmodels.co.uk>
Cc: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] Announce: zfsdump
Message-ID: <eb3a216e-dfd0-40fa-932c-65a8aee4f...@sun.com>
Content-Type: text/plain; CHARSET=US-ASCII
On Jun 28, 2010, at 12:26 PM, Tristram Scott wrote:
I use Bacula which works very well (much better than
Amanda did).
You may be able to customize it to do direct zfs
send/receive, however I find that although they are
great for copying file systems to other machines,
they are inadequate for backups unless you always
intend to restore the whole file system. Most people
want to restore a file or directory tree of files,
not a whole file system. In the past 25 years of
backups and restores, I've never had to restore a
whole file system. I get requests for a few files,
or somebody's mailbox or somebody's http document
root.
You can directly install it from CSW (or blastwave).
Thanks for your comments, Brian. I should look at Bacula in more detail.
As for full restore versus ad hoc requests for files I just deleted, my
experience is mostly similar to yours, although I have had need for full system
restore more than once.
For the restore of a few files here and there, I believe this is now well
handled with zfs snapshots. I have always found these requests to be down to
human actions. The need for full system restore has (almost) always been
hardware failure.
If the file was there an hour ago, or yesterday, or last week, or last month,
then we have it in a snapshot.
If the disk died horribly during a power outage (grrr!) then it would be very
nice to be able to restore not only the full file system, but also the
snapshots too. The only way I know of achieving that is by using zfs send etc.
I like snapshots when I'm making a major change to the system or for cloning. So to me,
snapshots are good for transaction based operations. Such as stopping & flushing a
database, take a snapshot, then resume the database. Then you can back up the snapshot with
Bacula and destroy the snapshot when the backup is complete. I have Bacula configured with a
pre-backup and post-backup scripts to do just that. When you do the restore, it will create
something that "looks" like a snapshot from the file system perspective, but isn't
really one.
But if you're looking for a copy of a file from a specific date, Bacula retains
that. In fact you specify the retention period you want and you'll have access
to any/all individual files on a per date basis. You can retain the files for
months or years if you like, and you specify that in the Bacula config file as
to how long you want to keep the tapes around. So it really comes down to your
use-case.
------------------------------
_______________________________________________
zfs-discuss mailing list
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
End of zfs-discuss Digest, Vol 56, Issue 126
********************************************
