date:20100119

Thomas Burgess wonsl...@gmail.com wrote:

 so star is better than tar?

Star is the oldest OSS tar implementation (it started in 1982).
Star is (in contrary to Sun's tar and to GNU tar) able to create
archives with attributes from recent POSIX standards and it implements
aprox. twice as many features than GNU tar without forcing you to learn
twice as many options ;-)

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Edward Ned Harvey sola...@nedharvey.com wrote:

  I still believe that a set of compressed incremental star archives give
  you
  more features.

 Big difference there is that in order to create an incremental star archive,
 star has to walk the whole filesystem or folder that's getting backed up,
 and do a stat on every file to see which files have changed since the last
 backup run.  If you have a large filesystem, that can take a very long time.

Star implements this in a very effective way (by using libfind) that is even 
faster that the find(1) implementation from Sun.

The big advantage with star is that you get OS and filesystem independent
archives that are compatible with recent POSIX standards and thus can be read 
on any POSIX.1-2001 compliant OS even if you don't have a star binary handy.

 I run incremental zfs send  receive, and it completes typically in a minute
 or two.

Did you make a test with star?

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Lassi Tuura l...@cern.ch wrote:

 I guess what I am after is, for data which really matters to its owners and 
 which they actually had to recover, did people use tar/pax archives (~ file 
 level standard archive format), dump/restore (~ semi-standard format based on 
 files/inodes) or zfs send/receive (~ file system block level dump), or 
 something else, and why? (Regardless of how these are implemented, hobby 
 scripts or enterprise tools, how they dealt with possible media failure 
 issues, etc.)

star combines the advantages from ufsdump/ufsrestore (true incremental dumps)
with the advantages of a POSIX standard achive format.

Note that star is even at least 30% faster that ufsdump (although ufsdump
reads the raw disk device while star uses the official OS filesystem interface).

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Miles Nordin car...@ivy.net wrote:

 When we brought it up last time, I think we found no one knows of a
 userland tool similar to 'ufsdump' that's capable of serializing a ZFS
 along with holes, large files, ``attribute'' forks, windows ACL's, and
 checksums of its own, and then restoring the stream in a
 filesystem-agnostic read/write/lseek/... manner like 'ufsrestore'.

Star is such a tool. It privides all the features known from ufsdump
but it is OS and filesystem indepentent. 

Once Sun shows interest in star, there will of course be also support 
for NTFS-ACLs.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Richard Elling richard.ell...@gmail.com wrote:

 OOB, the default OpenSolaris PATH places /usr/gnu/bin ahead
 of /usr/bin, so gnu tar is the default.  As of b130 (I'm not running
 an older build currently) the included gnu tar is version 1.22 which
 is the latest as released March 2009 at http://www.gnu.org/software/tar/

This causes Indiana to by default offer tar implementation that creates archives
that are in conflict with the POSIX standard.

Also note that GNU tar is unable to be used as a backup utility:

-   It does neither support ACLs not any other file attributes.

-   It failes even with simples modifications in the original filesystem
and people will become aware of this problem at the time when
they try to restore a backup that will not work in many cases.


 That is my understanding as well.  It seems that the backup vendors
 are moving forward in a more-or-less vendor-specific way. This is
 not necessarily a bad thing, since there are open source solutions.
 But I see the requirements for backups being much more sophisticated
 than ufsdump was 25 years ago.  hmmm... has ufsdump changed over 
 the past 25 years? ;-)

ufsdump did (slightly) change as it now allows you to specify a subdirectory
instead of the whole filesystem.

But what features are you missing?

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Daniel Carosone d...@geek.com.au wrote:

 I also don't recommend files 1Gb in size for DVD media, due to
 iso9660 limitations.  I haven't used UDF enough to say much about any
 limitations there.

ISO-9660 supports files up to 8 TB. Do you have a bigger pool?

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Is ZFS internal reservation excessive?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/18/2010 09:37 PM, Peter Jeremy wrote:
 Maybe it would be useful if ZFS allowed the reserved space to be
 tuned lower but, at least for ZFS v13, the reserved space seems to
 actually be a bit less than is needed for ZFS to function reasonably.

In fact, filling a 1.5 terabyte ZFS disk (leaving the 1.5% implicit
reservation alone) reduces my write speed to half (and this is using BIG
files 512MB)n. But it seems more a implementation artifact than a
natural law. For instance when we have the block rewrite, we can
coallesce free space to be able to find it easily  fast.

If I understand correctly, with this implicit reservation I don't need
(anymore) to create a dummy dataset with a small (64MBytes) reservation
to be sure I can delete files, etc., when the disk is full. That was
important to have in the beginning of ZFS. Can I forget this
requirement in modern ZFS implementations?.

I think ZFS doesn't reserves space for root, so you better have the
root (and /tmp and /var, if separate datasets) separate from
normal user fillable datasets. Is this correct?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
El amor es poner tu felicidad en la felicidad de otro - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS1WiT5lgi5GaxT1NAQJjlAP/eB2yfMGsRObul9lvuD31i3Z6kn43zTGH
ZBzSA9BKJS+UZmuWrOm8ncjkKZPiHyozoEEQzf4PpyseiusqGZV25kw6dE1xFrym
coRCN3ViUP1oBtXXNNYkm7OEZ5ksZTGVCwCe+rnCcrYPlnYv1I3yd60wb7+Z/r00
qh6ngQuus0o=
=UlGT
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Is ZFS internal reservation excessive?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/18/2010 09:45 PM, Mattias Pantzare wrote:
 No, the reservation in UFS/FFS is to keep the performance up. It will
 be harder and harder to find free space as the disk fills. Is is even
 more important for ZFS to be able to find free space as all writes
 need free space.
 
 The root-thing is just a side effect.

I stand corrected.

I think ZFS doesn't allow root to eat from the implicit reservation,
so we lose the side effect. Am I right?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
El amor es poner tu felicidad en la felicidad de otro - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS1Wi/Jlgi5GaxT1NAQLnlQP/XMGZNGRMHhYhKQERROi85aSFF5v8AZAW
8UrVZB+UgUComoSIBTyFa0dZ1COI/AVR5907me5oTKQEWqnL7CguDBoeElb6jjJM
OIkwu2TjInXhlpn9NLQpyvUdw3ERRKUAoJ1ki5lW9w7BPH3eGJs9mPw2NRdSBmcx
aJFN/7KqIWA=
=GruR
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Is ZFS internal reservation excessive?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/19/2010 12:25 AM, Erik Trimble wrote:
[Block rewrite]
 Once all this gets done, I'd think we seldom would need more than a GB
 or two as reserve space...

I agree. Without block rewrite, is best to have a percentage instead of
hard limit. After block rewrite, better to have a maximum absolute
limit, since free space will be easy to find.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
El amor es poner tu felicidad en la felicidad de otro - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS1WlsZlgi5GaxT1NAQKVNwQAjLM+9Us7Phw+h6FaLe+ovzPVNHuFKa59
ouc7J+3NckiFpTdidZNqb7n9qEAg1QIswjSAHm54J/KlMgdNpGTVvrAE/zGqac5U
GrXhgTVvuDxtlUP1+9Ff8O+e8EkJTMD+fGP2eAhL7kyry8xOdJ/ilrw20BSK4dl3
ZpTkdHqS25s=
=Jy30
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Is ZFS internal reservation excessive?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/19/2010 01:14 AM, Richard Elling wrote:
 For example, b129
 includes a fix for CR6869229, zfs should switch to shiny new metaslabs more
 frequently.
 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6869229
 I think the CR is worth reading if you have an interest in allocators and 
 performance.

Where is the docs?. That link has little info.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
El amor es poner tu felicidad en la felicidad de otro - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS1WnYZlgi5GaxT1NAQJEmQP/dADR6R6eCsNFCnfbPk0yETsHnXiiLT5Q
gZEOdKpIrefdy23fLDEYvvtMkiPRI3VmnIQwQTjqnmJCW1tNtn8ZO8+dkzAY2GDO
72FA8KuBOswAil/KTyuvGcXSpVX8qZz8DS+CQvP2eRGUXNueoqgzvDUN+TJMYLV4
xImE7eEiLxQ=
=mDYf
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] how are free blocks are used?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/19/2010 01:37 AM, Rodney Lindner wrote:
 Hi all,
 I was wondering, when blocks are freed as part COW process are the old blocks 
 put on the top or bottom of the freeblock list?
 
 The question came about looking a thin provisioning using zfs  on top of 
 dynamically expanding disk images (VDI). If the free blocks are put at the end
 free block list, over time the VDI will grow to its maximum size before it 
 reuses any of the blocks.

Check the thread Thin device support in ZFS?, from late december.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
El amor es poner tu felicidad en la felicidad de otro - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBS1Wo/plgi5GaxT1NAQKTrwP7ByYbXKDtZqMosqwj2zu34rx0ja/cQ9aw
AM2Ui6feTYNYxCrPqvHyFgybqdy0GY0iRJvSIbJI3qu/huG3LOVBz4GpEx0zffWn
0baAH9u1KqHMSOMTa1b64hgPIu7Eby09V2LKcV0I0/CKyys0qbp1Yothbm0LW5io
ehtVN9xTxwk=
=+tt0
-END PGP SIGNATURE-
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] New Supermicro SAS/SATA controller: AOC-USAS2-L8e in SOHO NAS and HD HTPC

2010-01-19 Thread Dusan Kysel

Supermicro AOC-USASLP-L8i has been confirmed to work flawlessly on OpenSolaris 
by several users on these forums already and is AFAIK widely considered the 
best controller for building custom Opensolaris ZFS NAS servers 
price/performance/compatibility wise in both SOHO NAS and HD HTPC scenarios.


Now Supermicro is shipping a new controller type with 8 internal 6Gb/s SAS/SATA 
ports which seems to be an even better investment:

http://www.supermicro.com/products/accessories/addon/AOC-USAS2-L8i.cfm?TYP=E


1) Can anyone confirm it is fully compatible with Opensolaris?

2) Is it as stable as AOC-USAS2-L8e? Are there any known drawbacks compared to 
AOC-USAS2-L8e?

3) Does hot-swap cause any problems?

4) Does it support staggered spin-up?

5) The spec states it Supports 122 devices as HBA in IT mode. Does this only 
imply you may connect more than 8 SAS drives via SAS Expanders or can you as 
well connect more than 8 SATA drives (e.g. via SATA Port Multipliers)?

6) Which ZFS pool configurations and connection schemes would you recommend to 
consider on a single server with 1-2 of these controllers in SOHO NAS and HD 
HTPC usage scenarios considering differences in performance characteristics, 
single raidz array expansion/upgrade CAPEX, HBA failure/corruption resiliency, 
etc.? (e.g. 4-disc raidz1 arrays vs. 8-disc raidz2 arrays vs. ...; all discs in 
the same raidz array connected to same controller vs. half of them connected to 
each controller)

7) Any further suggestions on choosing Opensolaris ZFS SOHO NAS and HD HTPC 
related hardware are welcome (suitable SSDs for ZIL, better 5-to-3 hot-swap 
internal backplane HDD cage than ICY DOCK MB455SPF-B, consumer HDDs more 
suitable than Samsung HD103UJ [1TB, 7200rpm, NCQ], recommended RAM size/type, 
...)


-dusan
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Unavailable device

2010-01-19 Thread John

I've got an LDOM that has raw disks exported through redundant service domains 
from a J4400. Actually, I've got seven of these LDOM's. On Friday, we had to 
power the rack down for UPS maintenance. We gracefully shutdown all the Solaris 
instances, waited about 15 min, then powered down the storage.

All of the LDOM's came up except one. They each have a mirrored RPOOL on 2 of 
these drives. The one with the problem shows the rpool as a mirror, with both 
devices online but the pool's unavailable. There's a message at the bottom that 
says:

Additional devices are known to be part of this pool, though their
exact configuration cannot be determined.

Only two disks were EVER part of this LDOM, and it's an rpool, so no raidz or 
stripe even possible. Anyone know how I can get past this?
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] NearLine SAS?

2010-01-19 Thread Tim Cook

On Tue, Jan 19, 2010 at 4:17 AM, Andrew Gabriel andrew.gabr...@sun.comwrote:


 Actually, this sounds like really good news for ZFS.
 ZFS (or rather, Solaris) can make good use of the multi-pathing capability,
 only previously available on high speed drives.
 Of course, ZFS can make use of any additional IOPs to be had, again only
 previously available on high speed drives.
 However, ZFS generally doesn't need high speed drives and does much better
 with hybrid storage pools.

 So these drives sound to me to have been designed specifically for ZFS!
 It's hard to imagine any other filesystem which can exploit them so
 completely.



You mean like WAFL?

-- 
--Tim
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Jerry K


+1

for zfsdump/zfsrestore



Julian Regel wrote:



When we brought it up last time, I think we found no one knows of a
userland tool similar to 'ufsdump' that's capable of serializing a ZFS
along with holes, large files, ``attribute'' forks, windows ACL's, and
checksums of its own, and then restoring the stream in a
filesystem-agnostic read/write/lseek/... manner like 'ufsrestore'.


This has been something I've been working on for the last few days and I've not 
yet found an adequate solution. I've looked at tar, cpio and pax as potential 
tools for backing up a ZFS filesystem to tape, but each has limitations. As of 
today, Sun do not provide the ability to reliably backup a Solaris installation 
without resorting to third party tools. This is crazy!

The beauty of ufsdump/ufsrestore is that because it's bundled with the 
operating system, I can perform bare metal recovery using a Solaris DVD and 
locally attached tape drive. It's simple and arguably essential for system 
administrators.

From my perspective, Sun really need to create a zfsdump/zfsrestore set of 
commands that perform block level backups of a specified filesystem (or 
snapshot) and that preserves ACLs, atime, sparse files, handles multiple tapes 
(many of us still use and rely on tape!) etc.

Does anyone know the process to formally request this (we have a support 
contract), or would I be wasting my time?

Thanks

JR

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss



  





___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] adpu320 scsi timeouts only with ZFS

2010-01-19 Thread Andreas Grüninger

Maybe there are too many I/Os for this controller.

You may try this settings
B130
echo zfs_txg_synctime_ms/W0t2000 | mdb -kw 
echo zfs_vdev_max_pending/W0t5 | mdb -kw 

older versions
echo zfs_txg_synctime/W0t2 | mdb -kw 
echo zfs_vdev_max_pending/W0t5 | mdb -kw 

Andreas
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Is ZFS internal reservation excessive?

2010-01-19 Thread Richard Elling

On Jan 19, 2010, at 4:36 AM, Jesus Cea wrote:
On 01/19/2010 01:14 AM, Richard Elling wrote:
For example, b129
includes a fix for CR6869229, zfs should switch to shiny new metaslabs more
frequently.
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6869229
I think the CR is worth reading if you have an interest in allocators and
performance.

Where is the docs?. That link has little info.

Jeff wrote a high-level overview of the allocation here:
http://blogs.sun.com/bonwick/entry/zfs_block_allocation

Finally, UTSL. There are several allocators already implemented: first
fit, best fit, and dynamic block (uses first fit until a threshold is reached
where it changes to best fit). The default is dynamic block. The source
also contains a CDF and NDF allocator, but I'm not sure if or where
they are used, they are commented as being experimental [*].
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/metaslab.c

For those not inclined to read source, there is already a method defined
for a metaslab to be marked as fragmented. This can be used to improve
Jeff's #2 item, metaslab selection. If you want to explore your pool, try
zdb -m poolname
zdb -mmm poolname
and wish you had my spacemaps from space code :-)
http://blogs.sun.com/relling/entry/space_maps_from_space

[*] opportunity for fame and glory, invent the perfect allocator :-)

-- richard

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Richard Elling

On Jan 19, 2010, at 1:53 AM, Julian Regel wrote:
  When we brought it up last time, I think we found no one knows of a
  userland tool similar to 'ufsdump' that's capable of serializing a ZFS
  along with holes, large files, ``attribute'' forks, windows ACL's, and
  checksums of its own, and then restoring the stream in a
  filesystem-agnostic read/write/lseek/... manner like 'ufsrestore'.
 
 This has been something I've been working on for the last few days and I've 
 not yet found an adequate solution. I've looked at tar, cpio and pax as 
 potential tools for backing up a ZFS filesystem to tape, but each has 
 limitations. As of today, Sun do not provide the ability to reliably backup a 
 Solaris installation without resorting to third party tools. This is crazy!
 
 The beauty of ufsdump/ufsrestore is that because it's bundled with the 
 operating system, I can perform bare metal recovery using a Solaris DVD and 
 locally attached tape drive. It's simple and arguably essential for system 
 administrators.

Yep. And it was invented because there was no option other than tar
at the time. Today, there are many very comprehensive backup solutions
on the market including open source. Some are nicely integrated, such 
as NexentaStor and Zmanda.

 From my perspective, Sun really need to create a zfsdump/zfsrestore set of 
 commands that perform block level backups of a specified filesystem (or 
 snapshot) and that preserves ACLs, atime, sparse files, handles multiple 
 tapes (many of us still use and rely on tape!) etc.

In my crystal ball, I see a divergence away from traditional backup 
solution approaches. Today you can feel comfortable with backing up
ZFS file systems because they provide a POSIX file system interface.
Other datasets don't resemble POSIX file systems at all, and I see several
different types of datasets with the opportunity to become popular with
the basic ZVol getting a lot of attention lately. The win will go to the 
vendor who can provide the best value for the various datasets in the ZFS
environment.

 Does anyone know the process to formally request this (we have a support 
 contract), or would I be wasting my time?

You can pile onto CR 5004379, want comprehensive backup strategy
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5004379

I can't answer the latter, but judging by the date of the CR, I wouldn't hold my
breath. Give the fine folks at Zmanda a look.

Also, the ADM project seems to be dead. Unfortunate?
http://hub.opensolaris.org/bin/view/Project+adm/WhatisADM
 -- richard

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Tim Cook

On Tue, Jan 19, 2010 at 11:36 AM, Richard Elling
richard.ell...@gmail.comwrote:

 On Jan 19, 2010, at 1:53 AM, Julian Regel wrote:
   When we brought it up last time, I think we found no one knows of a
   userland tool similar to 'ufsdump' that's capable of serializing a ZFS
   along with holes, large files, ``attribute'' forks, windows ACL's, and
   checksums of its own, and then restoring the stream in a
   filesystem-agnostic read/write/lseek/... manner like 'ufsrestore'.
 
  This has been something I've been working on for the last few days and
 I've not yet found an adequate solution. I've looked at tar, cpio and pax as
 potential tools for backing up a ZFS filesystem to tape, but each has
 limitations. As of today, Sun do not provide the ability to reliably backup
 a Solaris installation without resorting to third party tools. This is
 crazy!
 
  The beauty of ufsdump/ufsrestore is that because it's bundled with the
 operating system, I can perform bare metal recovery using a Solaris DVD and
 locally attached tape drive. It's simple and arguably essential for system
 administrators.

 Yep. And it was invented because there was no option other than tar
 at the time. Today, there are many very comprehensive backup solutions
 on the market including open source. Some are nicely integrated, such
 as NexentaStor and Zmanda.

  From my perspective, Sun really need to create a zfsdump/zfsrestore set
 of commands that perform block level backups of a specified filesystem (or
 snapshot) and that preserves ACLs, atime, sparse files, handles multiple
 tapes (many of us still use and rely on tape!) etc.

 In my crystal ball, I see a divergence away from traditional backup
 solution approaches. Today you can feel comfortable with backing up
 ZFS file systems because they provide a POSIX file system interface.
 Other datasets don't resemble POSIX file systems at all, and I see several
 different types of datasets with the opportunity to become popular with
 the basic ZVol getting a lot of attention lately. The win will go to the
 vendor who can provide the best value for the various datasets in the ZFS
 environment.

  Does anyone know the process to formally request this (we have a support
 contract), or would I be wasting my time?

 You can pile onto CR 5004379, want comprehensive backup strategy
 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5004379

 I can't answer the latter, but judging by the date of the CR, I wouldn't
 hold my
 breath. Give the fine folks at Zmanda a look.

 Also, the ADM project seems to be dead. Unfortunate?
 http://hub.opensolaris.org/bin/view/Project+adm/WhatisADM
  -- richard



I'm likely missing something, so please, fill me in.  Aren't they simply
asking for the functionality already provided by NDMP?

-- 
--Tim
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] NearLine SAS?

2010-01-19 Thread A. Krijgsman


I was today reasearching this same phenomenon.
The multipath is required for HA storage solutions with redundant i/o path 
backplanes and redundant controllers.

( If a controller fails, the other one can still access the harddisk.)

I read about an LSI SAS-to-SATA bridge what can be attacched onto an 
ordinary SATA
drive to make it operate like a SAS drive (e.g. be able to multi path to 
that drive.)

Is there anyone on the list that can give some information about this?

I am google-ing my pants of to find some kind of shop selling these bridges.
I want to build a redundant JBOD to share between two ZFS 
hosts.(Active/Standby)


I already found the nearline SAS disks, but this will not fix the multipath 
problem for SATA SSD disks.


Regards,
Armand



- Original Message - 
From: Erik Trimble erik.trim...@sun.com

To: Tim Cook t...@cook.ms
Cc: zfs-discuss zfs-discuss@opensolaris.org
Sent: Tuesday, January 19, 2010 8:06 AM
Subject: Re: [zfs-discuss] NearLine SAS?



Tim Cook wrote:



On Tue, Jan 19, 2010 at 12:16 AM, Erik Trimble erik.trim...@sun.com 
mailto:erik.trim...@sun.com wrote:


A poster in another forum mentioned that Seagate (and Hitachi,
amongst others) is now selling something labeled as NearLine SAS
storage  (e.g. Seagate's NL35 series).

Is it me, or does this look like nothing more than their standard
7200-rpm enterprise drives with a SAS or FC interface instead of a
SATA one?

I can't see any real advantage of those over the existing
enterprise SATA drives (e.g. Seagate's Constellation ES series),
other than not needing a FC/SAS-SATA gateway in the external
drive enclosure.



Seagate claims the SAS versions of their drives actually see IOPS 
improvements:

http://www.seagate.com/www/en-us/products/servers/barracuda_es/barracuda_es.2

If the SAS version is dual ported like I would expect, that's also a 
MAJOR benefit.


--
--Tim
stupid question here:  I understand the advantages of dual-porting a drive 
with a FC interface, but for SAS, exactly what are the advantages other 
than being able to read and write simultaneously (obviously, only from the 
on-drive cache).
And yeah, these Seagates are dual-ported SAS. (according to the spec 
sheet)


Also, a 38% increase in IOPS without LESS drive cache seems unlikely.  Or, 
at least highly workload-dependent.
Check that, they're claiming 38% better IOPS/watt over the SATA version, 
which, given that the SAS one pulls 10% more watts, means in absolute 
terms 45% or so.   I'm really skeptical that only an interface change can 
do that.



--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss 


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] New ZFS Intent Log (ZIL) device available - Beta program now open!

2010-01-19 Thread Christopher George

 From the web page it looks like this is a card that goes into the
 computer system.  That's not very useful for enterprise applications, 
 as they are going to want to use an external array that can be used 
 by a redundant pair of servers.

The DDRdrive X1 does utilize a half-length/full-height/two-slot PCIe plug-in
card form factor.  So for systems such as the Sun Storage 7310/7410, we
are not a solution.  Sun does offer a Write Flash Accelerator (Logzilla) to
satisfy both single and clustered controller configurations.

Our intention is to provide enterprise customers (non-clustered) an
additional option.

Thanks,

Christopher George
Founder/CTO
www.ddrdrive.com
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] NearLine SAS?

2010-01-19 Thread Errol Neal

On Tue, Jan 19, 2010 01:02  PM, A. Krijgsman a.krijgs...@draftsman.nl wrote:
 I was today reasearching this same phenomenon.
 The multipath is required for HA storage solutions with redundant i/o path 
 backplanes and redundant controllers.
 ( If a controller fails, the other one can still access the harddisk.)
 
 I read about an LSI SAS-to-SATA bridge what can be attacched onto an 
 ordinary SATA
 drive to make it operate like a SAS drive (e.g. be able to multi path to 
 that drive.)
 Is there anyone on the list that can give some information about this?
 
 I am google-ing my pants of to find some kind of shop selling these bridges.
 I want to build a redundant JBOD to share between two ZFS 
 hosts.(Active/Standby)
 
 I already found the nearline SAS disks, but this will not fix the multipath 
 problem for SATA SSD disks.
 
 Regards,
 Armand

I assume you mean these type of interposer cards?

e.g 
http://www.lsi.com/DistributionSystem/AssetDocument/SCG_LSISS9252_PB_082709.pdf

Based on my experiences, they generally go to VARs or OEMs e.g. Dell, HP. I do 
recall seeing some older gens on a 2950 that passed my way..
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] NearLine SAS?

2010-01-19 Thread Errol Neal


On Tue, Jan 19, 2010 01:36  PM, A. Krijgsman a.krijgs...@draftsman.nl wrote:
 Yes, those i meant! (interposer cards, could get on that name!)
 The Dell's and HP's would al work in any enviroment?
 
 It's just plain converting between industry standards right?
 
 Or do people have a better solution to share a single SSD from a JBOD 
 between
 two hosts?
 
 Regards,
 Armand
 

Perhaps I didn't read your post in it's entirety. If your goal is to share a 
single drive between two jbod systems, an interposer card won't help.

There was some talk on the list about sharing SSDs over low latency networks. 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Julian Regel

The beauty of ufsdump/ufsrestore is that because it's bundled with the
operating system, I can perform bare metal recovery using a Solaris DVD and
locally attached tape drive. It's simple and arguably essential for system
administrators.

Yep. And it was invented because there was no option other than tar
at the time. Today, there are many very comprehensive backup solutions
on the market including open source. Some are nicely integrated, such
as NexentaStor and Zmanda.

When I look at the documentation for Zmanda
(http://docs.zmanda.com/Project:Amanda_Enterprise_3.0/ZMC_Users_Manual/Appendix_A:_Backing_Up_and_Restoring_Solaris_ZFS),
it states that the command used to backup a ZFS filesystem depends on whether
backing up ACLs are required (the default is not to(!)). If backing up ACLs are
required - which they are for us - then the native /usr/bin/tar command is
used. Given that /usr/bin/tar doesn't handle sparse files correctly and updates
atime when creating archives, it's not possible to create a complete copy of a
filesystem without making intrusive changes to the structure of the data and/or
metadata.

So it's arguable that ufsdump was a significant improvement over tar, and that
the current archiving solutions for ZFS are actually a step backwards.

From my perspective, Sun really need to create a zfsdump/zfsrestore set of
commands that perform block level backups of a specified filesystem (or
snapshot) and that preserves ACLs, atime, sparse files, handles multiple
tapes (many of us still use and rely on tape!) etc.

In my crystal ball, I see a divergence away from traditional backup
solution approaches. Today you can feel comfortable with backing up
ZFS file systems because they provide a POSIX file system interface.

Based on what I've seen in other comments, you might be right. Unfortunately, I
don't feel comfortable backing up ZFS filesystems because the tools aren't
there to do it (built into the operating system or using Zmanda/Amanda).

I know tape backup isn't sexy, but it's a reality for many of us and it's not
going away anytime soon.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?


Julian Regel wrote:


Based on what I've seen in other comments, you might be right. 
Unfortunately, I don't feel comfortable backing up ZFS filesystems 
because the tools aren't there to do it (built into the operating 
system or using Zmanda/Amanda).



Commercial backup solutions are available for ZFS.
I know tape backup isn't sexy, but it's a reality for many of us and 
it's not going away anytime soon.


True, but I wonder how viable its future is.  One of my clients requires 
17 LT04 types for a full backup, which cost more and takes up more space 
than the equivalent in removable hard drives.


In the past few years growth in hard drive capacities has outstripped 
tapes to the extent that removable hard drives and ZFS snapshots have 
become a more cost effective and convenient backup media.


What do people with many tens of TB use for backup these days?

--
Ian.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Julian Regel jrmailgate-zfsdisc...@yahoo.co.uk wrote:

When I look at the documentation for Zmanda
(http://docs.zmanda.com/Project:Amanda_Enterprise_3.0/ZMC_Users_Manual/Appendix_A:_Backing_Up_and_Restoring_Solaris_ZFS),
it states that the command used to backup a ZFS filesystem depends on
whether backing up ACLs are required (the default is not to(!)). If backing
up ACLs are required - which they are for us - then the native /usr/bin/tar
command is used. Given that /usr/bin/tar doesn't handle sparse files
correctly and updates atime when creating archives, it's not possible to
create a complete copy of a filesystem without making intrusive changes to
the structure of the data and/or metadata.

So it's arguable that ufsdump was a significant improvement over tar, and
that the current archiving solutions for ZFS are actually a step backwards.

Sun's tar is not able to archive files 8 GB in a way that can be read on any
other OS unless you use star. This is because Sun's tar does not implement
support for the POSIX.1-2001 extended tar format.

Sun's tar also writes ACLs in a way that is 100% non-portable. Star cannot
understand them and probably never will be able to understand this format as it
is not well defined for a portable program like star.

Star supports to do backups without affecting atime (on Solaris) since 15 years
already and star supports the withdrawn POSIX draft ACLs in a OS independent
way. This allows to use star for platform independent ACL support in case you
are using UFS on Solaris.

Star will in future support NTFS ACLs in a OS independent way. If someone likes
to contribute, he is of course welcome. As I am currently working on
cdrtools-3.0-final, star is currently on maintenance only.

What we need for the future is a OS/FS independent program that implements the
needed features.

Jörg

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de(uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Panic running a scrub

2010-01-19 Thread Frank Middleton


This is probably unreproducible, but I just got a panic whilst
scrubbing a simple mirrored pool on scxe snv124. Evidently
on of the disks went offline for some reason and shortly
thereafter the panic happened. I have the dump and  the
/var/adm/messages containing the trace.

Is there any point in submitting a bug report?

The panic starts with:

Jan 19 13:27:13 host6 ^Mpanic[cpu1]/thread=2a1009f5c80:
Jan 19 13:27:13 host6 unix: [ID 403854 kern.notice] assertion failed: 0 == 
zap_update(dp-dp_meta_objset, DMU_POOL_DIRECTORY_OBJECT, DMU_POOL_SCRUB_BOOKMARK, 
sizeof (uint64_t), 4, dp-dp_scrub_bookmark, tx), file: 
../../common/fs/zfs/dsl_scrub.c, line: 853

FWIW when the system came back up, it resilvered with no
problem and now I'm rerunning the scrub.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?


Joerg Schilling wrote:

Ian Collins i...@ianshome.com wrote:

  

Julian Regel wrote:

Based on what I've seen in other comments, you might be right. 
Unfortunately, I don't feel comfortable backing up ZFS filesystems 
because the tools aren't there to do it (built into the operating 
system or using Zmanda/Amanda).


  

Commercial backup solutions are available for ZFS.



On what archiving programs are these solutions based on?

  
I'm sure they use their own formats.  The only one I have crossed paths 
with is NetVault.


--
Ian.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?


On Wed, 20 Jan 2010, Ian Collins wrote:

Commercial backup solutions are available for ZFS.
I know tape backup isn't sexy, but it's a reality for many of us and it's 
not going away anytime soon.


True, but I wonder how viable its future is.  One of my clients requires 17 
LT04 types for a full backup, which cost more and takes up more space than 
the equivalent in removable hard drives.


In the past few years growth in hard drive capacities has outstripped tapes 
to the extent that removable hard drives and ZFS snapshots have become a more 
cost effective and convenient backup media.


In all of these discussions, people seem to forget some very important 
criteria.  That important criteria is the time required for a full 
recovery from backup.


If the company is not able to survive more than a week with total 
disruption of business, but the full restore will take three weeks, 
then the backup has been rendered 100% ineffective.


When planning for recovery from disaster, the time to recover is 
exceedingly important.


When using the backup to filesystem approach, that backup could be 
done to a remote mirrored system (filesystems + hardware) which is 
sufficiently distant to protect against any local disaster.  If there 
is a disaster in the local data center, that system could be 
immediately put on line (assuming adequate connectivity), or that 
system could be loaded on a truck for overnight delivery as a 
replacement to the data center.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] ZFS System Tuning - Solaris 10 u8

2010-01-19 Thread Mr. T Doodle

Running Solaris 10 u8 and ZFS.
Has anyone found a need to tune the kernel with the values below?

*Solaris 10 10/09*: This release includes the zfs_arc_min and
zfs_arc_maxparameter descriptions. For more information, see
zfs_arc_min http://docs.sun.com/app/docs/doc/817-0404/gjheb?a=view and
zfs_arc_max http://docs.sun.com/app/docs/doc/817-0404/gjhec?a=view.

*Solaris 10 10/09*: This release includes the ddi_msix_alloc_limit parameter
that can be used to increase the number of MSI-X interrupts that a device
instance can allocate. For more information, see
ddi_msix_alloc_limithttp://docs.sun.com/app/docs/doc/817-0404/gihas?a=view
.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Panic running a scrub


On Tue, 19 Jan 2010, Frank Middleton wrote:


This is probably unreproducible, but I just got a panic whilst
scrubbing a simple mirrored pool on scxe snv124. Evidently
on of the disks went offline for some reason and shortly
thereafter the panic happened. I have the dump and  the
/var/adm/messages containing the trace.

Is there any point in submitting a bug report?


I seem to recall that you are not using ECC memory.  If so, maybe the 
panic is a good thing.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

Ian Collins i...@ianshome.com wrote:

  Sun's tar also writes ACLs in a way that is 100% non-portable. Star cannot 
  understand them and probably never will be able to understand this format 
  as it
  is not well defined for a portable program like star.
 

 Is that because they are NFSv4 ACLs?  tar uses the formatting routines 
 from libacl to archive them.

The correct way to archivbe ACLs would be to put them into extended POSIX tar
attrubutes as star does.

See http://cdrecord.berlios.de/private/man/star/star.4.html for a format 
documentation or have a look at ftp://ftp.berlios.de/pub/star/alpha, e.g.
ftp://ftp.berlios.de/pub/star/alpha/acl-test.tar.gz

The ACL format used by Sun is undocumented..


Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Miles Nordin

 jk == Jerry K sun.mail.lis...@oryx.cc writes:

jk +1 
jk for zfsdump/zfsrestore

-1

I don't think a replacement for the ufsdump/ufsrestore tool is really
needed.  From now on, backups just go into Another Zpool.

We need the zfs send stream format commitment (stream format depends
only on zfs version, not on zpool version or kernel version), but
that's enough.


If people are really still backing up to tapes or DVD's, just use file
vdev's, export the pool, and then copy the unmounted vdev onto the
tape or DVD.  The requirement that your backup be staged on a disk
isn't an obstacle in the backup direction: Amanda already has this
requirement.  Amanda, when I used it, did *not* have this requirement
in the restore direction so one would have to keep that in mind: if
using tapes, he needs a scratch disk as big as the biggest tape file
on the DR site or the development environment or Compliance Extractor
Station or wherever the restore is happening.

File vdev's have all the wanted characteristics: bitflip resiliency,
checksums, ability to represent all the opaque mysteryfeatures of
inner ZFS's, snapshot/clone efficiency, and importability by future
ZFS kernels ~forever.  It still has the all-or-nothing-restore
downside, but maybe we can live with that.  Those who can't might
stick to spinning-disk backups.

It might be nice to have a ``read-only vdev'' like a mac os compressed
disk image that can occupy the same pool next to a read-write
vdev---this would be neat for livecd's and incrementals---but it's a
neat feature, not something blocking a frequent/unavoidable sysadmin
task.

What's needed IMHO is non-ZFS-specific tools like tar/pax/cpio/rsync
that understand all this new ACL and opaque-fork garbage that
filesystems are growing (and not just Sun's either).  It's needed to
copy between NFSv4 and ZFS, and also to split/combine subdirectories
into separate/common ZFS filesystems without losing any of the
newfangled mysterybaggage.  It has as much to do with shaking corner
cases and awkwardnesses out of the newfangled API's as it does with
actually accomplishing a sysadmin task: the best documentation for the
weird appendages in various modern Unix filesystems would probably be
the tool itself, if we had it.  

Without this kind of tool and the API shakeout that making it would
require, our systems are slowly turning into shitty Windows boxes that
need some black magic proprietary tool like Ghost or PQDI to capture
all the silly out-of-band garbage their installations depend on and/or
accumulate.


pgpnDeqTYeOuV.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] opensolaris-vmware

2010-01-19 Thread Gregory Durham

Thank you so much Fajar,
You have been incredibly helpful! I will do as you said I am just glad I
have not been going down the wrong path!

Thanks,
Greg

On Thu, Jan 14, 2010 at 4:45 PM, Fajar A. Nugraha fa...@fajar.net wrote:

 On Fri, Jan 15, 2010 at 12:33 AM, Gregory Durham
 gregory.dur...@gmail.com wrote:
  I have been recommended by several other users on this mailing list to
 use
  inside the vm snapshots, vmware snapshots, and then use zfs snapshots. I
  believe I understand the difference between filesystem snapshots vs block
  level snapshots, however since I cannot use vmware snapshots (all LUNs on
  the SAN are mapped to ESXi using RAW disk in physical compatibility mode,
  which then disables vmware snapshots) does this cause me to have a weaker
  backup strategy? What else can I do? Should I convert the virtual
 machines
  from physical compatibility to virtual compatibility in order to get
  snapshotting on the ESXi server?

 IMHO using all three is too much. you can pick one, and combine that
 with other (non-snapshot) backup strategy.
 vmware snapshot is good because it also stores memory state, but it
 also uses more space.

 What I recommend you to do in your current setup:
 - check whether your application can survive an unclean shutdown/power
 outage (it should). If not, then you have to do application-specific
 backup.
 - do zfs snapshot plus send/receive
 - add regular tape backup if necessary, although it might not need to
 be as frequent (you already plan this)
 - regulary excercise restoring from backups, to make sure your backup
 system works.

 --
 Fajar

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Miles Nordin

 ic == Ian Collins i...@ianshome.com writes:

  I know tape backup isn't sexy, but it's a reality for many of
  us and it's not going away anytime soon.

ic True, but I wonder how viable its future is.  One of my
ic clients requires 17 LT04 types for a full backup, which cost
ic more and takes up more space than the

but Ian, aiui SOX requires backups onto a write-once non-eraseable
medium, because of all the discovery shennanigans and
claimed-incompetence around the time of the Worldcomm and Enron
bankruptcy near the start of Bush II.  The law in practice is sort of
like a tiger that chases the herd and eats the sick animal that's
lagging behind, and currently I think the herd is using ``WORM tape''
which is a tape that's made to appear to be append-only by the tape
drive's firmware.  These tapes exist now and must be retained for
seven years, so even if you invented a newfangled gadget meeting the
WORM requirements TODAY so that you can stay in the middle of the herd
without using tape, you still will not get rid of tape for seven
years.


pgp2HKJuL5cLI.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Daniel Carosone

On Tue, Jan 19, 2010 at 12:16:01PM +0100, Joerg Schilling wrote:
 Daniel Carosone d...@geek.com.au wrote:
 
  I also don't recommend files 1Gb in size for DVD media, due to
  iso9660 limitations.  I haven't used UDF enough to say much about any
  limitations there.
 
 ISO-9660 supports files up to 8 TB. 

However, some implementations have (or had?) limitations which meant
that they couldn't read such disks.  Some of those platforms even had
problems (or required remembering arcane options and flags for large
file support) when copying these files back to hard disk.  

Linux was a prime culprit, though not the only one.  I didn't use
linux, but I never knew what might be at hand when needing to read
disks for recovery, so I wanted them to be portable.  I envisaged
using multiple machines to read more disks in parallel, for example.

It may not be as relevant for this use case, nor perhaps for more
modern platforms, but it was a habit I developed earlier for other
kinds of archives. 

I apologise, though, for misattributing this limitation to the
filesystem spec.  I misremembered the reason why I chose the limit.
It was a practical limit, and the practicalities may well have changed
since.

 Do you have a bigger pool?

I certainly don't have a bigger DVD media :-)

(Yes, I know iso9660 also has multivolume support, but I'm similarly
wary of being able to read it back on all platforms, since it's not
encountered often, and there's no need when the source files can be
split to better effect.)

--
Dan.


pgpqa8vKafJ1t.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] ZFS/NFS/LDOM performance issues

2010-01-19 Thread Scott Duckworth

[Cross-posting to ldoms-discuss]

We are occasionally seeing massive time-to-completions for I/O requests on ZFS 
file systems on a Sun T5220 attached to a Sun StorageTek 2540 and a Sun J4200, 
and using a SSD drive as a ZIL device.  Primary access to this system is via 
NFS, and with NFS COMMITs blocking until the request has been sent to disk, 
performance has been deplorable.  The NFS server is a LDOM domain on the T5220.

To give an idea of how bad the situation is, iotop from the DTrace Toolkit 
occasionally reports single I/O requests to 15k RPM FC disks that take more 
than 60 seconds to complete, and even requests to a SSD drive that take over 10 
seconds to complete.  It's not uncommon to open a small text file using vim (or 
similar editor) and nothing to pop up for 10-30 seconds.  Browsing the web 
becomes a chore, as the browser locks up for a few seconds after doing anything.

I have a full write-up of the situation at 
http://www.cs.clemson.edu/~duckwos/zfs-performance/.  Any thoughts or comments 
are welcome.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Daniel Carosone

There is a tendency to conflate backup and archive, both generally
and in this thread. They have different requirements.  

Backups should enable quick restore of a full operating image with all
the necessary system level attributes. They concerned with SLA and
uptime and outage and data loss window criteria. 

Archives are usually much more concerned with application data, which
may have been specially prepared for the future user of the
archive. Portability is often more important here, both in archive
format but also in data schema within, even at the expense of some
kinds of technical integrity or completeness (e.g. ACLs).

Adding regulatory requirements into the mix further complicates matters.

If one solution can address the union of all requirements, then you're
in luck, but that's not always the case.  Sometimes the best way to
resolve the tension is to save the data differently for different
purposes. 

--
Dan.

pgpfsQPyUEOVE.pgp
Description: PGP signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS/NFS/LDOM performance issues

2010-01-19 Thread Ray Van Dolson

On Tue, Jan 19, 2010 at 02:24:11PM -0800, Scott Duckworth wrote:
 [Cross-posting to ldoms-discuss]
 
 We are occasionally seeing massive time-to-completions for I/O
 requests on ZFS file systems on a Sun T5220 attached to a Sun
 StorageTek 2540 and a Sun J4200, and using a SSD drive as a ZIL
 device.  Primary access to this system is via NFS, and with NFS
 COMMITs blocking until the request has been sent to disk, performance
 has been deplorable.  The NFS server is a LDOM domain on the T5220.
 
 To give an idea of how bad the situation is, iotop from the DTrace
 Toolkit occasionally reports single I/O requests to 15k RPM FC disks
 that take more than 60 seconds to complete, and even requests to a
 SSD drive that take over 10 seconds to complete.  It's not uncommon
 to open a small text file using vim (or similar editor) and nothing
 to pop up for 10-30 seconds.  Browsing the web becomes a chore, as
 the browser locks up for a few seconds after doing anything.
 
 I have a full write-up of the situation at
 http://www.cs.clemson.edu/~duckwos/zfs-performance/.  Any thoughts or
 comments are welcome.  -- 

Could your SSD be having problems?  Got another to swap in and compare
against?

Ray
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Unavailable device

2010-01-19 Thread Cindy Swearingen


Hi John,

The message below is a ZFS message, but its not enough to figure out
what is going on in an LDOM environment. I don't know of any LDOMs
experts that hang out on this list so you might post this on the
ldoms-discuss list, if only to get some more troubleshooting data.

I think you are saying that the LDOM that is not coming up has a
mirrored root pool on 2 devices...

You might be able to use the following command to see if the disk
labels are coherent for each these devices for the broken LDOM's
root pool:

# zdb -l /dev/dsk/x

Maybe someone else has some better ideas ...

Cindy

On 01/19/10 07:48, John wrote:

I've got an LDOM that has raw disks exported through redundant service domains 
from a J4400. Actually, I've got seven of these LDOM's. On Friday, we had to 
power the rack down for UPS maintenance. We gracefully shutdown all the Solaris 
instances, waited about 15 min, then powered down the storage.

All of the LDOM's came up except one. They each have a mirrored RPOOL on 2 of 
these drives. The one with the problem shows the rpool as a mirror, with both 
devices online but the pool's unavailable. There's a message at the bottom that 
says:

Additional devices are known to be part of this pool, though their
exact configuration cannot be determined.

Only two disks were EVER part of this LDOM, and it's an rpool, so no raidz or 
stripe even possible. Anyone know how I can get past this?

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Allen Eastwood

 Message: 3
 Date: Tue, 19 Jan 2010 15:48:52 -0500
 From: Miles Nordin car...@ivy.net
 To: zfs-discuss@opensolaris.org
 Subject: Re: [zfs-discuss] zfs send/receive as backup - reliability?
 Message-ID: oqpr55lt1n@castrovalva.ivy.net
 Content-Type: text/plain; charset=us-ascii

 I don't think a replacement for the ufsdump/ufsrestore tool is really
 needed.  From now on, backups just go into Another Zpool.

 We need the zfs send stream format commitment (stream format depends
 only on zfs version, not on zpool version or kernel version), but
 that's enough.

 If people are really still backing up to tapes or DVD's, just use file
 vdev's, export the pool, and then copy the unmounted vdev onto the
 tape or DVD.  The requirement that your backup be staged on a disk
 isn't an obstacle in the backup direction: Amanda already has this
 requirement.  Amanda, when I used it, did *not* have this requirement
 in the restore direction so one would have to keep that in mind: if
 using tapes, he needs a scratch disk as big as the biggest tape file
 on the DR site or the development environment or Compliance Extractor
 Station or wherever the restore is happening.

While this idea may be fine for a home user…those us of who have customers in 
the enterprise still have a need for tape backups.

And some of those enterprises require backup mechanism that can be easily used 
in a DR situation.

ufsdump/restore was perfect in that regard.  The lack of equivalent 
functionality is a big problem for the situations where this functionality is a 
business requirement.

For example, one customer, local government, requires a backup that can be 
taken offsite and used in a DR situation.  They have 2 sun servers.  They have 
very little Solaris knowledge. So whatever I provide them has to be easy and 
easily documented.  Lack of zfsdump/restore means I either have to forgo 
moving them to ZFS root, or have to add in a third party application…like I'm 
really going to meet their requirements with Amanda or Backula…

This lack in Solaris is just plain ludicrous to at least some parts of the 
business/enterprise world.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS/NFS/LDOM performance issues


On Tue, 19 Jan 2010, Scott Duckworth wrote:


[Cross-posting to ldoms-discuss]

We are occasionally seeing massive time-to-completions for I/O 
requests on ZFS file systems on a Sun T5220 attached to a Sun 
StorageTek 2540 and a Sun J4200, and using a SSD drive as a ZIL 
device.  Primary access to this system is via NFS, and with NFS 
COMMITs blocking until the request has been sent to disk, 
performance has been deplorable.  The NFS server is a LDOM domain on 
the T5220.


What is the output of 'zpool status' for this pool?  What is the 
output of 'iostat -xe'?


Have you verified that your StorageTek 2540 firmware is up to date? 
BTFW that new firmware comes with new CAM software, which does not 
seem to be announced in any useful fashion so you won't know about it 
unless you poll the Sun Downloads site. I have not seen any stalling 
problems with my StorageTek 2540 here.


I agree with Ray Van Dolson that the evidence supplied thus far points 
to an issue with the SSD.  Perhaps the system is noticing a problem 
and is continually resetting it.  Check for messages in 
/var/adm/messages.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Panic running a scrub

2010-01-19 Thread David Magda


On Jan 19, 2010, at 14:30, Frank Middleton wrote:


This is probably unreproducible, but I just got a panic whilst
scrubbing a simple mirrored pool on scxe snv124. Evidently
on of the disks went offline for some reason and shortly
thereafter the panic happened. I have the dump and  the
/var/adm/messages containing the trace.

Is there any point in submitting a bug report?


Was a crash dump generated? If so, then there's a chance that it can  
be tracked down I would guess.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Richard Elling

On Jan 19, 2010, at 4:26 PM, Allen Eastwood wrote:

 Message: 3
 Date: Tue, 19 Jan 2010 15:48:52 -0500
 From: Miles Nordin car...@ivy.net
 To: zfs-discuss@opensolaris.org
 Subject: Re: [zfs-discuss] zfs send/receive as backup - reliability?
 Message-ID: oqpr55lt1n@castrovalva.ivy.net
 Content-Type: text/plain; charset=us-ascii

 I don't think a replacement for the ufsdump/ufsrestore tool is really
 needed.  From now on, backups just go into Another Zpool.

 We need the zfs send stream format commitment (stream format depends
 only on zfs version, not on zpool version or kernel version), but
 that's enough.

 If people are really still backing up to tapes or DVD's, just use file
 vdev's, export the pool, and then copy the unmounted vdev onto the
 tape or DVD.  The requirement that your backup be staged on a disk
 isn't an obstacle in the backup direction: Amanda already has this
 requirement.  Amanda, when I used it, did *not* have this requirement
 in the restore direction so one would have to keep that in mind: if
 using tapes, he needs a scratch disk as big as the biggest tape file
 on the DR site or the development environment or Compliance Extractor
 Station or wherever the restore is happening.

 While this idea may be fine for a home user…those us of who have customers in 
 the enterprise still have a need for tape backups.

 And some of those enterprises require backup mechanism that can be easily 
 used in a DR situation.

 ufsdump/restore was perfect in that regard.  The lack of equivalent 
 functionality is a big problem for the situations where this functionality is 
 a business requirement.

How quickly we forget ufsdump's limitations :-).  For example, it is not 
supported
for use on an active file system (known data corruption possibility) and 
UFS snapshots are, well, a poor hack and often not usable for backups.
As the ufsdump(1m) manpage says,
 The ufsdump command can only be used on unmounted file  sys-
 tems,  or  those  mounted  read-only.  Attempting  to dump a
 mounted, read-write file system might  result  in  a  system
 disruption  or the inability to restore files from the dump.
 Consider using the fssnap(1M) command to create a file  sys-
 tem  snapshot  if  you  need a point-in-time image of a file
 system that is mounted.

So, if you are taking ufsdumps of an active file system for business 
requirements,
then perhaps you should rethink the solution.

 For example, one customer, local government, requires a backup that can be 
 taken offsite and used in a DR situation.  They have 2 sun servers.  They 
 have very little Solaris knowledge. So whatever I provide them has to be easy 
 and easily documented.  Lack of zfsdump/restore means I either have to 
 forgo moving them to ZFS root, or have to add in a third party 
 application…like I'm really going to meet their requirements with Amanda or 
 Backula…

Many people use send/recv or AVS for disaster recovery on the inexpensive
side. Obviously, enterprise backup systems also provide DR capabilities.
Since ZFS has snapshots that actually work, and you can use send/receive
or other backup solutions on snapshots, I assert the problem is low priority.

 This lack in Solaris is just plain ludicrous to at least some parts of the 
 business/enterprise world.

Methinks you never read the ufsdump man page? :-)
 -- richard

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Allen Eastwood


On Jan 19, 2010, at 18:48 , Richard Elling wrote:

 
 Many people use send/recv or AVS for disaster recovery on the inexpensive
 side. Obviously, enterprise backup systems also provide DR capabilities.
 Since ZFS has snapshots that actually work, and you can use send/receive
 or other backup solutions on snapshots, I assert the problem is low 
 priority.
 


 What I have issue with is the idea that no one uses/should use tape any more.  
There are places for tape and it still has value as a backup device.  In many 
cases in the past, ufsdump, despite it's many issues, was able to restore 
working OS's, or individual files.  Perfect, not by a long shot.  But it did 
get the job done. 

As was pointed out earlier, all I needed was a Solaris CD (or network boot) and 
I could restore.  Entire OS gone, boot and ufsrestore.  Critical files deleted, 
same thing…and I can restore just the file(s) I need.  And while it's been a 
few years since I've read the man page on ufsdump, ufsrestore and fssnap, those 
tools have proven useful when dealing with a downed system.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS/NFS/LDOM performance issues

2010-01-19 Thread Scott Duckworth

No errors reported on any disks.

$ iostat -xe
 extended device statistics  errors --- 
devicer/sw/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
vdc0  0.65.6   25.0   33.5  0.0  0.1   17.3   0   2   0   0   0   0 
vdc1 78.1   24.4 3199.2   68.0  0.0  4.4   43.3   0  20   0   0   0   0 
vdc2 78.0   24.6 3187.6   67.6  0.0  4.5   43.5   0  20   0   0   0   0 
vdc3 78.1   24.4 3196.0   67.9  0.0  4.5   43.5   0  21   0   0   0   0 
vdc4 78.2   24.5 3189.8   67.6  0.0  4.5   43.7   0  21   0   0   0   0 
vdc5 78.3   24.4 3200.3   67.9  0.0  4.5   43.5   0  21   0   0   0   0 
vdc6 78.4   24.6 3186.5   67.7  0.0  4.5   43.5   0  21   0   0   0   0 
vdc7 76.4   25.9 3233.0   67.4  0.0  4.2   40.7   0  20   0   0   0   0 
vdc8 76.7   26.0 3222.5   67.1  0.0  4.2   41.1   0  21   0   0   0   0 
vdc9 76.5   26.0 3233.9   67.7  0.0  4.2   40.8   0  20   0   0   0   0 
vdc1076.5   25.7 3221.6   67.2  0.0  4.2   41.5   0  21   0   0   0   0 
vdc1176.4   25.9 3228.2   67.4  0.0  4.2   41.1   0  20   0   0   0   0 
vdc1276.4   26.1 3216.2   67.4  0.0  4.3   41.6   0  21   0   0   0   0 
vdc13 0.08.70.3  248.4  0.0  0.01.8   0   0   0   0   0   0 
vdc1495.38.2 2919.3   28.2  0.0  2.5   24.3   0  21   0   0   0   0 
vdc1595.99.4 2917.6   26.2  0.0  2.1   19.7   0  19   0   0   0   0 
vdc1695.38.0 2924.3   28.2  0.0  2.6   25.5   0  22   0   0   0   0 
vdc1796.19.4 2920.5   26.2  0.0  2.0   19.3   0  19   0   0   0   0 
vdc1895.48.2 2923.3   28.2  0.0  2.4   23.4   0  21   0   0   0   0 
vdc1995.89.3 2903.2   26.2  0.0  2.5   24.3   0  21   0   0   0   0 
vdc2095.08.4 2877.6   28.1  0.0  2.5   23.9   0  21   0   0   0   0 
vdc2195.99.5 2848.2   26.2  0.0  2.6   24.3   0  21   0   0   0   0 
vdc2295.08.4 2874.3   28.1  0.0  2.5   23.7   0  21   0   0   0   0 
vdc2395.79.5 2854.0   26.2  0.0  2.5   23.4   0  21   0   0   0   0 
vdc2495.18.4 2883.9   28.1  0.0  2.4   23.5   0  21   0   0   0   0 
vdc2595.69.4 2839.3   26.2  0.0  2.8   26.5   0  22   0   0   0   0 
vdc26 0.06.90.2  319.8  0.0  0.02.6   0   0   0   0   0   0 

Nothing sticks out in /var/adm/messages on either the primary or cs0 domain.

The SSD is a recent addition (~3 months ago), and was added in an attempt to 
counteract the poor performance we were already seeing without the SSD.

I will check firmware versions tomorrow.  I do recall updating the firmware 
about 8 months ago when we upgraded CAM to support the new J4200 array.  At the 
time, it was the most recent CAM release available, not the outdated version 
that shipped on the CD in the array package.

My supervisor pointed me to http://forums.sun.com/thread.jspa?threadID=5416833 
which describes what seems to be an identical problem.  It references 
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6547651 which was 
reported to be fixed in Solaris 10 update 4.  No solution was posted, but it 
was pointed out that a similar configuration without LDOMs in the mix provided 
superb performance.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?

2010-01-19 Thread Mike La Spina

I use zfs send/recv in the enterprise and in smaller environments all time and 
it's is excellent.

Have a look at how awesome the functionally is in this example.

http://blog.laspina.ca/ubiquitous/provisioning_disaster_recovery_with_zfs

Regards,

Mike
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS/NFS/LDOM performance issues


On Tue, 19 Jan 2010, Scott Duckworth wrote:


No errors reported on any disks.

Nothing sticks out in /var/adm/messages on either the primary or cs0 domain.


Thus far there is no evidence that there is anything wrong with your 
storage arrays, or even with zfs. The problem seems likely to be 
somewhere else in the kernel.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Problems with send/receive

2010-01-19 Thread Matthew Ahrens


John Meyer wrote:

Looks like this part got cut off somehow:

the filesystem mount point is set to /usr/local/local.  I just want to
do a simple backup/restore, can anyone tell me something obvious that I'm not 
doing right?

Using OpenSolaris development build 130.


Sounds like bug 6916662, fixed in build 132.

--matt
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Clearing a directory with more than 60 million files

2010-01-19 Thread Matthew Ahrens


Michael Schuster wrote:

Mike Gerdts wrote:

On Tue, Jan 5, 2010 at 4:34 AM, Mikko Lammi mikko.la...@lmmz.net wrote:

Hello,

As a result of one badly designed application running loose for some 
time,

we now seem to have over 60 million files in one directory. Good thing
about ZFS is that it allows it without any issues. Unfortunatelly now 
that

we need to get rid of them (because they eat 80% of disk space) it seems
to be quite challenging.

Traditional approaches like find ./ -exec rm {} \; seem to take 
forever
- after running several days, the directory size still says the same. 
The

only way how I've been able to remove something has been by giving rm
-rf to problematic directory from parent level. Running this command
shows directory size decreasing by 10,000 files/hour, but this would 
still

mean close to ten months (over 250 days) to delete everything!

I also tried to use unlink command to directory as a root, as a 
user who
created the directory, by changing directory's owner to root and so 
forth,

but all attempts gave Not owner error.

Any commands like ls -f or find will run for hours (or days) without
actually listing anything from the directory, so I'm beginning to 
suspect

that maybe the directory's data structure is somewhat damaged. Is there
some diagnostics that I can run with e.g zdb to investigate and
hopefully fix for a single directory within zfs dataset?


In situations like this, ls will be exceptionally slow partially
because it will sort the output. 


that's what '-f' was supposed to avoid, I'd guess.


Yes, but unfortunately, the typical reason ls is slow with huge directories 
is that it requires a huge amount of memory.  Even when not sorting (with 
-f), it still allocates a huge amount of memory for each entry listed, and 
buffers the output until the directory is entirely read.  So typically -f 
doesn't help performance much.  Improving this would be a great small project 
for an OpenSolaris contributor!  I filed a couple of bugs for this several 
years ago, I can dig them up if anyone is interested.


--matt
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Unavailable device

2010-01-19 Thread John

I was able to solve it, but it actually worried me more than anything.

Basically, I had created the second pool using the mirror as a primary device. 
So three disks but two full disk root mirrors.

Shouldn't zpool have detected an active pool and prevented this? The other LDOM 
was claiming a corrupted device, which I was able to replace and clear easily. 
But the one pool I originally posted about looks to be permanently gone, since 
it believes there is another device, but doesn't know where the device is or 
what it was ever called. If I could import it and re-do the mirror somehow, or 
something similar, it'd be great. Is there anyway to force it to realize it's 
wrong?

Obviously, I should've kept better track of the WWN's - But I've made the 
mistake before and zpool always prevented it.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS/NFS/LDOM performance issues

2010-01-19 Thread Scott Duckworth

 Thus far there is no evidence that there is anything wrong with your
 storage arrays, or even with zfs. The problem seems likely to be
 somewhere else in the kernel.

Agreed.  And I tend to think that the problem lays somewhere in the LDOM 
software.  I mainly just wanted to get some experienced eyes on the problem to 
see if anything sticks out before I go through the trouble of reinstalling the 
system without LDOMs (the original need for VMs in this application no longer 
exists).
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?


Joerg Schilling wrote:

Ian Collins i...@ianshome.com wrote:

  
Sun's tar also writes ACLs in a way that is 100% non-portable. Star cannot 
understand them and probably never will be able to understand this format as it

is not well defined for a portable program like star.

  
  
Is that because they are NFSv4 ACLs?  tar uses the formatting routines 
from libacl to archive them.



The correct way to archivbe ACLs would be to put them into extended POSIX tar
attrubutes as star does.

See http://cdrecord.berlios.de/private/man/star/star.4.html for a format 
documentation or have a look at ftp://ftp.berlios.de/pub/star/alpha, e.g.

ftp://ftp.berlios.de/pub/star/alpha/acl-test.tar.gz

The ACL format used by Sun is undocumented..

  

man acltotext

--
Ian.

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zfs send/receive as backup - reliability?