Re: [zfs-discuss] [Fwd: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion in snv 128]

[Daniel Carosone]

I welcome the re-write.  The deficiencies of the current snapshot cleanup 
implementation have been a source of constant background irritation to me for a 
while, and the subject of a few bugs.

Regarding the issues in contention

 - the send hooks capability is useful and should remain, but the 
implementation of it may and probably should be vastly different.   I don't 
think it's a terrible thing if the capability remains, even if it requires some 
adjustment in the implementation of scripts people have written to make them 
work in the new world.  That blurs the line a little in terms of interface 
commitment.
 - I really would like better separation between gui and service, in particular 
the dependency on a whole garden full of gnomes and X libs.   I don't want 
these on my cut down storage appliance.

In general:

It seems there's scope and opportunity to separate the taking and removing of 
snapshots by the service from other actions that may be triggered (send, etc).  
 I don't think you want those hooks executing in the context or process of the 
service, for a number of reasons.  Wouldn't it be better to have some events 
published on the creation and deletion of snapshots, and a separate service 
that can listen to those events and trigger hooks and actions (eg. replication, 
including the established interface) accordingly?  In general, why should my 
snapshot replication mechanism specifically be limited to snapshots triggered 
by the auto-snapshot svc?

I'm also concerned about the sleep interval of the service, which as described 
sleeps until the next scheduled snapshot.  This is all very well in general, 
except that if I disable some of the shorter-period snapshots (say, only daily 
and above) I only get daily checks against the space threshold.  Room for 
improvement here.

Would there be a way to avoid taking snapshots if they're going to be 
zero-sized?  There's a whole separate set of discussion about whether deleting 
the 0-size snapshots is a good idea or not, entangled with some of the current 
implementation issues.  However, to avoid unnecessary disk access (power save 
spin-ups) it would be nice to avoid making snapshots and then deleting them 
again straight after (and calling hooks on them :-).  This probably needs a zfs 
change for a "discretionary snapshot" only if the fs has changed since the 
previous one.

The rsync project will be a whole separate design effort.  It would be nice for 
this to consider both "backing up zfs snapshots via rsync to remote " as well as "backing up remote  to zfs with snaphots", 
notionally similar to rsnapshot and other similar implementations.

--
Dan.

(posted here, rather than in response to the mailing list reference given, 
because I'm not subscribed and because I never knew that mailing list existed 
since it's apparently not visible as a web forum).
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] Recovering FAULTED zpool

[Peter Jeremy]

I have a zpool on a JBOD SE3320 that I was using for data with Solaris
10 (the root/usr/var filesystems were all UFS).  Unfortunately, we had
a bit of a mixup with SCSI cabling and I believe that we created a
SCSI target clash.  The system was unloaded and nothing happened until
I ran "zpool status" at which point things broke.  After correcting
all the cabling, Solaris panic'd before reaching single user.

Sun Support could only suggest restoring from backups - but
unfortunately, we do not have backups of some of the data that we
would like to recover.

Since OpenSolaris has a much newer version of ZFS, I thought I would
give OpenSolaris a try and it looks slightly more promising, though I
still can't access the pool.  The following is using snv125 on a T2000.

r...@als253:~# zpool import -F data
Nov 17 15:26:46 opensolaris zfs: WARNING: can't open objset for data/backup
r...@als253:~# zpool status -v data
  pool: data
 state: FAULTED
status: An intent log record could not be read.
Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
or ignore the intent log records by running 'zpool clear'.
   see: http://www.sun.com/msg/ZFS-8000-K4
 scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data FAULTED  0 0 3  bad intent log
  raidz2-0   DEGRADED 0 018
c2t8d0   FAULTED  0 0 0  too many errors
c2t9d0   ONLINE   0 0 0
c2t10d0  ONLINE   0 0 0
c2t11d0  ONLINE   0 0 0
c2t12d0  ONLINE   0 0 0
c2t13d0  ONLINE   0 0 0
c3t8d0   ONLINE   0 0 0
c3t9d0   ONLINE   0 0 0
c3t10d0  ONLINE   0 0 0
c3t11d0  ONLINE   0 0 0
c3t12d0  DEGRADED 0 0 0  too many errors
c3t13d0  ONLINE   0 0 0
r...@als253:~# zpool online data c2t8d0
Nov 17 15:28:42 opensolaris zfs: WARNING: can't open objset for data/backup
cannot open 'data': pool is unavailable
r...@als253:~# zpool clear data
cannot clear errors for data: one or more devices is currently unavailable
r...@als253:~# zpool clear -F data
cannot open '-F': name must begin with a letter
r...@als253:~# zpool status data
  pool: data
 state: FAULTED
status: One or more devices are faulted in response to persistent errors.  
There are insufficient replicas for the pool to
continue functioning.
action: Destroy and re-create the pool from a backup source.  Manually marking 
the device
repaired using 'zpool clear' may allow some data to be recovered.
 scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data FAULTED  0 0 1  corrupted data
  raidz2-0   FAULTED  0 0 6  corrupted data
c2t8d0   FAULTED  0 0 0  too many errors
c2t9d0   ONLINE   0 0 0
c2t10d0  ONLINE   0 0 0
c2t11d0  ONLINE   0 0 0
c2t12d0  ONLINE   0 0 0
c2t13d0  ONLINE   0 0 0
c3t8d0   ONLINE   0 0 0
c3t9d0   ONLINE   0 0 0
c3t10d0  ONLINE   0 0 0
c3t11d0  ONLINE   0 0 0
c3t12d0  DEGRADED 0 0 0  too many errors
c3t13d0  ONLINE   0 0 0
r...@als253:~#

Annoyingly, data/backup is not a filesystem I'm especially worried
about - I'd just like to get access to the other filesystems on it.
Is is possible to hack the pool to make data/backup just disappear.
For that matter:
1) Why is the whole pool faulted when n-2 vdevs are online?
2) Given that metadata is triplicated, where did the objset go?

-- 
Peter Jeremy


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

Re: [zfs-discuss] ZFS storage server hardware

[Ian Allison]

Hi Bruno,


Bruno Sousa wrote:

Hi Ian,

I use the Supermicro SuperChassis 846E1-R710B, and i added the JBOD kit 
that has :


* Power Control Card


Sorry to keep bugging you, but which card is this. I like the sound of 
your setup.


Cheers,
Ian.




* SAS 846EL2/EL1 BP External Cascading Cable

* SAS 846EL1 BP 1-Port Internal Cascading Cable

I don't do any monitoring in the JBOD chassis..
Bruno

Ian Allison wrote:

Hi Bruno,

Bruno Sousa wrote:

Hi,

I currently have a 1U server (Sun X2200) with 2 LSI HBA attached to a
Supermicro JBOD chassis each one with 24 disks , SATA 1TB, and so far so
good..
So i have a 48 TB raw capacity, with a mirror configuration for NFS
usage (Xen VMs) and i feel that for the price i paid i have a very 
nice system.


Sounds good. I understand from

http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg27248.html

That you need something like supermicro's CSE-PTJBOD-CB1 to cable the 
drive trays up, do you do anything about monitoring the power supply?


Cheers,
Ian.







--

Ian Allison
PIMS-UBC/SFU System and Network Administrator
the Pacific Institute for the Mathematical Sciences

Phone: (778) 991 1522
email: i...@pims.math.ca
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS storage server hardware

[Ed Jobs]

On Tuesday 17 November 2009 22:50, Ian Allison wrote:
> I'm learning as I go here, but as far as I've been able to determine,
> the basic choices for attaching drives seem to be
> 
> 1) SATA Port multipliers
> 2) SAS Multilane Enclosures
> 3) SAS Expanders
what about pci(-X) cards?
as stated in:
http://opensolaris.org/jive/thread.jspa?messageID=247226
you can use
http://www.supermicro.com/products/accessories/addon/AOC-SAT2-MV8.cfm
to add 8 more sata disks. why not use that (now that 2TB disks have been 
released)?

-- 
Real programmers don't document. If it was hard to write, it should be hard to 
understand.


signature.asc
Description: This is a digitally signed message part.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS ZIL/log on SSD weirdness

[Miles Nordin]

> "d" == Dushyanth   writes:

 d> Performance dropped for some reason

the SSD's black-box-filesystem is fragmented?  Do the slog-less test
again and see if it's still fast.


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

Re: [zfs-discuss] ZFS ZIL/log on SSD weirdness

[Richard Elling]

On Nov 17, 2009, at 2:50 PM, Scott Meilicke wrote:

I am sorry that I don't have any links, but here is what I observe  
on my system. dd does not do sync writes, so the ZIL is not used.  
iSCSI traffic does sync writes (as of 2009.06, but not 2008.05), so  
if you repeat your test using an iSCSI target from your system, you  
should see log activity. Same for NFS. I see no ZIL activity using  
rsync, for an example of a network file transfer that does not  
require sync.


This is correct.  Normal, local file I/O will be nicely cached.
 -- richard

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

Re: [zfs-discuss] building zpools on device aliases

[Andrew Gabriel]

sean walmsley wrote:

We have a number of Sun J4200 SAS JBOD arrays which we have multipathed using Sun's MPxIO 
facility. While this is great for reliability, it results in the /dev/dsk device IDs 
changing from cXtYd0 to something virtually unreadable like 
"c4t5000C5000B21AC63d0s3".

Since the entries in /dev/{rdsk,dsk} are simply symbolic links anyway, would there be any 
problem with adding "alias" links to /devices there and building our zpools on 
them? We've tried this and it seems to work fine producing a zpool status similar to the 
following:

...
NAMESTATE READ WRITE CKSUM
vol01   ONLINE   0 0 0
  mirrorONLINE   0 0 0
top00   ONLINE   0 0 0
bot00   ONLINE   0 0 0
  mirrorONLINE   0 0 0
top01   ONLINE   0 0 0
bot01   ONLINE   0 0 0
...

Here our aliases are "topnn" and "botnn" to denote the disks in the top and 
bottom JBODs.

The obvious question is "what happens if the alias link disappears?". We've tested this, 
and ZFS seems to handle it quite nicely by finding the "normal" /dev/dsk link and simply 
working with that (although it's more difficult to get ZFS to use the alias again once it is 
recreated).

If anyone can think of anything really nasty that we've missed, we'd appreciate 
knowing about it. Alternatively, if there is a better supported means of having 
ZFS display human-readable device ids we're all ears :-)

Perhaps an MPxIO RFE for "vanity" device names would be in order?
  


I recently raised RFE CR 6901193 "Need a command to list current usage 
of disks, partitions, and slices".

Unfortunately, it's still in triage so probably not yet visible externally.

Part of this RFE relates to a requirement for vanity naming of disks, 
although your requirement is a little different. If you are on support, 
you should get yourself added to the RFE, together with your precise 
requirements as above.


--
Andrew Gabriel

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

Re: [zfs-discuss] building zpools on device aliases

[Cindy Swearingen]

Hi Sean,

I sympathize with your intentions but providing pseudo-names for these
disks might cause more confusion than actual help.

The "c4t5..." name isn't so bad. I've seen worse. :-)

Here are the issues with using the aliases:

- If a device fails on a J4200, a LED will indicate which disk has
failed but will not identify the alias name.
- To prevent confusion with drive failures, you will need to map your
aliases to the disk names, possibly pulling out the disks and relabeling
them with the alias name. You might be able to use
/usr/lib/fm/fmd/fmtopo -V | grep disks to do these mappings online.
- We don't know what fmdump will indicate if a disk has problems, the
dev alias or the real disk name.
- We don't know what else might fail

The stress of mapping the alias names to real disk names, might happen
under duress, like when a disk fails. The physical disk ID on the disk
will be included in the expanded name, not the alias name.

The hardest part is getting the right disks in the pool. After that, it
gets easier. ZFS does a good job of identifying the devices in a pool
and will identify which disk is having problems as will the fmdump
command. The LEDs on the disks themselves also help disk replacements.

The wheels are turning to make device administration easier. We're just
not there yet.

Cindy

On 11/16/09 19:17, sean walmsley wrote:

We have a number of Sun J4200 SAS JBOD arrays which we have multipathed using Sun's MPxIO 
facility. While this is great for reliability, it results in the /dev/dsk device IDs 
changing from cXtYd0 to something virtually unreadable like 
"c4t5000C5000B21AC63d0s3".

Since the entries in /dev/{rdsk,dsk} are simply symbolic links anyway, would there be any 
problem with adding "alias" links to /devices there and building our zpools on 
them? We've tried this and it seems to work fine producing a zpool status similar to the 
following:

...
NAMESTATE READ WRITE CKSUM
vol01   ONLINE   0 0 0
  mirrorONLINE   0 0 0
top00   ONLINE   0 0 0
bot00   ONLINE   0 0 0
  mirrorONLINE   0 0 0
top01   ONLINE   0 0 0
bot01   ONLINE   0 0 0
...

Here our aliases are "topnn" and "botnn" to denote the disks in the top and 
bottom JBODs.

The obvious question is "what happens if the alias link disappears?". We've tested this, 
and ZFS seems to handle it quite nicely by finding the "normal" /dev/dsk link and simply 
working with that (although it's more difficult to get ZFS to use the alias again once it is 
recreated).

If anyone can think of anything really nasty that we've missed, we'd appreciate 
knowing about it. Alternatively, if there is a better supported means of having 
ZFS display human-readable device ids we're all ears :-)

Perhaps an MPxIO RFE for "vanity" device names would be in order?

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

Re: [zfs-discuss] ZFS ZIL/log on SSD weirdness

[Scott Meilicke]

I am sorry that I don't have any links, but here is what I observe on my 
system. dd does not do sync writes, so the ZIL is not used. iSCSI traffic does 
sync writes (as of 2009.06, but not 2008.05), so if you repeat your test using 
an iSCSI target from your system, you should see log activity. Same for NFS. I 
see no ZIL activity using rsync, for an example of a network file transfer that 
does not require sync.

Scott
-- 
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 ZIL/log on SSD weirdness

[Dushyanth]

I ran a quick test to confirm James theory - and there is more weirdness

# Mirror pool with two 500GB SATA disks - no log device

r...@m1-sv-zfs-1:~# zpool create pool1 mirror c8t5d0 c8t2d0
r...@m1-sv-zfs-1:~# zfs create pool1/fs
r...@m1-sv-zfs-1:~# cd /pool1/fs
r...@m1-sv-zfs-1:/pool1/fs# time dd if=/dev/zero of=bigfile.55 bs=4096 
count=100
100+0 records in
100+0 records out
409600 bytes (4.1 GB) copied, 41.2861 s, 99.2 MB/s

real0m41.290s
user0m0.634s
sys 0m12.907s

# Mirror pool with two 500GB locally attached SATA disks - with log device

r...@m1-sv-zfs-1:~# zpool add pool1 log c8t4d0
r...@m1-sv-zfs-1:~# zpool status pool1
  pool: pool1
 state: ONLINE
 scrub: none requested
config:

NAMESTATE READ WRITE CKSUM
pool1   ONLINE   0 0 0
  mirrorONLINE   0 0 0
c8t5d0  ONLINE   0 0 0
c8t2d0  ONLINE   0 0 0
logsONLINE   0 0 0
  c8t4d0ONLINE   0 0 0

r...@m1-sv-zfs-1:/pool1/fs# time dd if=/dev/zero of=bigfile.55 bs=4096 
count=100
100+0 records in
100+0 records out
409600 bytes (4.1 GB) copied, 51.0463 s, 80.2 MB/s

real0m51.107s
user0m0.639s
sys 0m12.817s

r...@m1-sv-zfs-1:/pool1/fs# time dd if=/dev/zero of=bigfile.66 bs=4096 
count=100
100+0 records in
100+0 records out
409600 bytes (4.1 GB) copied, 52.0175 s, 78.7 MB/s

real0m52.022s
user0m0.641s
sys 0m12.780s

Performance dropped for some reason and still no io activity on the log device 
(c8t4d0 - Transcend 8GB SSD disk)

TIA
Dushyanth
-- 
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 ZIL/log on SSD weirdness

[Dushyanth]

Oops - most important info missed - Its OpenSolaris 2009.06

# uname -a
SunOS m1-sv-ZFS-1 5.11 snv_111b i86pc i386 i86pc Solaris

TIA
Dushyanth
-- 
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 storage server hardware

[Chris Du]

You can get the E2 version of the chassis that supports multipathing but you 
have to use dual port SAS disks. Or you can use seperate SAS hba to connect to 
seperate jbos chassis and do mirror over 2 chassis. The backplane is just a 
path-through fabric which is very unlikely to die.

Then like others said, your storage head unit is single point of failure. 
Unless you implement some cluster design, there is always single point of 
failure.
-- 
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 ZIL/log on SSD weirdness

[Richard Elling]

Which OS and release?  The behaviour has changed over time.
 -- richard

On Nov 17, 2009, at 1:33 PM, Dushyanth wrote:


Hey guys,

Iam new to ZFS and have been playing around since few days. Iam  
trying to improve performance of a iSCSI storage backend by putting  
the ZIL/log on a SSD.


Below are the steps i followed

# format < /dev/null
Searching for disks...

The device does not support mode page 3 or page 4,
or the reported geometry info is invalid.
WARNING: Disk geometry is based on capacity data.

The current rpm value 0 is invalid, adjusting it to 3600
done

c8t3d0: configured with capacity of 465.74GB


AVAILABLE DISK SELECTIONS:
  0. c8t0d0 
 /p...@0,0/pci8086,3...@1f,2/d...@0,0
  1. c8t1d0 
 /p...@0,0/pci8086,3...@1f,2/d...@1,0
  2. c8t2d0 
 /p...@0,0/pci8086,3...@1f,2/d...@2,0
  3. c8t3d0 63>

 /p...@0,0/pci8086,3...@1f,2/d...@3,0
  4. c8t4d0 
 /p...@0,0/pci8086,3...@1f,2/d...@4,0
  5. c8t5d0 
 /p...@0,0/pci8086,3...@1f,2/d...@5,0
  6. c9t9d0 
 /iscsi/d...@iqn.2002-10.com.infortrend 
%3Araid.sn7755270.0010001,0

  7. c9t13d0 
 /iscsi/d...@0001iqn.2002-10.com.infortrend 
%3Araid.sn7755270.0010001,0

  8. c9t15d0 
 /iscsi/d...@0002iqn.2002-10.com.infortrend 
%3Araid.sn7755270.0010001,0

  9. c9t16d0 
 /iscsi/d...@0003iqn.2002-10.com.infortrend 
%3Araid.sn7755270.0010001,0

Specify disk (enter its number):

# zpool create iftraid0 c9t9d0 log c8t4d0
# zfs create iftraid0/fs

# zpool status iftraid0
 pool: iftraid0
state: ONLINE
scrub: none requested
config:

   NAMESTATE READ WRITE CKSUM
   iftraid0ONLINE   0 0 0
 c9t9d0ONLINE   0 0 0
   logsONLINE   0 0 0
 c8t4d0ONLINE   0 0 0

errors: No known data errors

Now when i run dd and create a big file on /iftraid0/fs and watch  
`iostat -xnz 2` i dont see any stats for c8t4d0 nor does the write  
performance improves.


I have not formatted either c9t9d0 or c8t4d0. What am i missing ?

TIA
Dushyanth
--
This message posted from opensolaris.org
___
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] ZFS storage server hardware

[Bruno Sousa]

Hi Ian,

I use the Supermicro SuperChassis 846E1-R710B, and i added the JBOD kit
that has :

* Power Control Card

* SAS 846EL2/EL1 BP External Cascading Cable

* SAS 846EL1 BP 1-Port Internal Cascading Cable

I don't do any monitoring in the JBOD chassis..
Bruno

Ian Allison wrote:
> Hi Bruno,
>
> Bruno Sousa wrote:
>> Hi,
>>
>> I currently have a 1U server (Sun X2200) with 2 LSI HBA attached to a
>> Supermicro JBOD chassis each one with 24 disks , SATA 1TB, and so far so
>> good..
>> So i have a 48 TB raw capacity, with a mirror configuration for NFS
>> usage (Xen VMs) and i feel that for the price i paid i have a very
>> nice system.
>
> Sounds good. I understand from
>
> http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg27248.html
>
> That you need something like supermicro's CSE-PTJBOD-CB1 to cable the
> drive trays up, do you do anything about monitoring the power supply?
>
> Cheers,
> Ian.
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS storage server hardware

[Ian Allison]

Hi Bruno,

Bruno Sousa wrote:

Hi,

I currently have a 1U server (Sun X2200) with 2 LSI HBA attached to a
Supermicro JBOD chassis each one with 24 disks , SATA 1TB, and so far so
good..
So i have a 48 TB raw capacity, with a mirror configuration for NFS
usage (Xen VMs) and i feel that for the price i paid i have a very nice 
system.


Sounds good. I understand from

http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg27248.html

That you need something like supermicro's CSE-PTJBOD-CB1 to cable the 
drive trays up, do you do anything about monitoring the power supply?


Cheers,
Ian.

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

Re: [zfs-discuss] ZFS ZIL/log on SSD weirdness

[James Lever]

On 18/11/2009, at 7:33 AM, Dushyanth wrote:

> Now when i run dd and create a big file on /iftraid0/fs and watch `iostat 
> -xnz 2` i dont see any stats for c8t4d0 nor does the write performance 
> improves. 
> 
> I have not formatted either c9t9d0 or c8t4d0. What am i missing ?

Last I checked, iSCSI volumes go direct to the primary storage and not via the 
slog device.

Can anybody confirm that is the case and if there is a mechanism/tuneable to 
force it via the slog and if there is any benefit/point in this for most cases?

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

Re: [zfs-discuss] ZFS storage server hardware

[Ian Allison]

Hi Richard,

Richard Elling wrote:


Cases like the Supermicro 846E1-R900B have 24 hot swap bays accessible 
via a single (4u) LSI SASX36 SAS expander chip, but I'm worried about 
controller death and having the backplane as a single point of failure.


There will be dozens of single point failures in your system.  Don't 
worry about
controllers or expanders because they will be at least 10x more reliable 
than
your disks.  If you want to invest for better reliability, invest in 
enterprise class

disks, preferably SSDs.
 -- richard


I agree about the points of failure, but I guess I'm not looking as much 
for reliability as I am for replacability. The motherboard, backplane 
and controllers are all reasonably priced (to the extent that if I had a 
few of these machine I would keep spares of everything on hand). They 
are also pretty generic so I could recycle them if I decided to go in a 
different direction.


Thanks,
Ian.

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

[zfs-discuss] ZFS ZIL/log on SSD weirdness

[Dushyanth]

Hey guys,

Iam new to ZFS and have been playing around since few days. Iam trying to 
improve performance of a iSCSI storage backend by putting the ZIL/log on a SSD.

Below are the steps i followed

# format < /dev/null
Searching for disks...

The device does not support mode page 3 or page 4,
or the reported geometry info is invalid.
WARNING: Disk geometry is based on capacity data.

The current rpm value 0 is invalid, adjusting it to 3600
done

c8t3d0: configured with capacity of 465.74GB


AVAILABLE DISK SELECTIONS:
   0. c8t0d0 
  /p...@0,0/pci8086,3...@1f,2/d...@0,0
   1. c8t1d0 
  /p...@0,0/pci8086,3...@1f,2/d...@1,0
   2. c8t2d0 
  /p...@0,0/pci8086,3...@1f,2/d...@2,0
   3. c8t3d0 
  /p...@0,0/pci8086,3...@1f,2/d...@3,0
   4. c8t4d0 
  /p...@0,0/pci8086,3...@1f,2/d...@4,0
   5. c8t5d0 
  /p...@0,0/pci8086,3...@1f,2/d...@5,0
   6. c9t9d0 
  /iscsi/d...@iqn.2002-10.com.infortrend%3araid.sn7755270.0010001,0
   7. c9t13d0 
  /iscsi/d...@0001iqn.2002-10.com.infortrend%3araid.sn7755270.0010001,0
   8. c9t15d0 
  /iscsi/d...@0002iqn.2002-10.com.infortrend%3araid.sn7755270.0010001,0
   9. c9t16d0 
  /iscsi/d...@0003iqn.2002-10.com.infortrend%3araid.sn7755270.0010001,0
Specify disk (enter its number):

# zpool create iftraid0 c9t9d0 log c8t4d0
# zfs create iftraid0/fs

# zpool status iftraid0
  pool: iftraid0
 state: ONLINE
 scrub: none requested
config:

NAMESTATE READ WRITE CKSUM
iftraid0ONLINE   0 0 0
  c9t9d0ONLINE   0 0 0
logsONLINE   0 0 0
  c8t4d0ONLINE   0 0 0

errors: No known data errors

Now when i run dd and create a big file on /iftraid0/fs and watch `iostat -xnz 
2` i dont see any stats for c8t4d0 nor does the write performance improves. 

I have not formatted either c9t9d0 or c8t4d0. What am i missing ?

TIA
Dushyanth
-- 
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 storage server hardware

[Angelo Rajadurai]

Also if you are a startup, there are some ridiculously sweet deals on Sun 
hardware through the Sun Startup Essentials program. 
http://sun.com/startups

This way you do not need to worry about compatibility and you get all the 
Enterprise RAS features at a pretty low price point.

-Angelo


On Nov 17, 2009, at 4:14 PM, Bruno Sousa wrote:

> Hi,
> 
> I currently have a 1U server (Sun X2200) with 2 LSI HBA attached to a
> Supermicro JBOD chassis each one with 24 disks , SATA 1TB, and so far so
> good..
> So i have a 48 TB raw capacity, with a mirror configuration for NFS
> usage (Xen VMs) and i feel that for the price i paid i have a very nice 
> system.
> 
> 
> Bruno
> 
> Ian Allison wrote:
>> Hi,
>> 
>> I know (from the zfs-discuss archives and other places [1,2,3,4]) that
>> a lot of people are looking to use zfs as a storage server in the
>> 10-100TB range.
>> 
>> I'm in the same boat, but I've found that hardware choice is the
>> biggest issue. I'm struggling to find something which will work nicely
>> under solaris and which meets my expectations in terms of hardware.
>> Because of the compatibility issues, I though I should ask here to see
>> what solutions people have already found.
>> 
>> 
>> I'm learning as I go here, but as far as I've been able to determine,
>> the basic choices for attaching drives seem to be
>> 
>> 1) SATA Port multipliers
>> 2) SAS Multilane Enclosures
>> 3) SAS Expanders
>> 
>> In option 1, the controller can only talk to one device at a time, in
>> option 2 each miniSAS connector can talk to 4 drives at a time but in
>> option 3 the expander can allow for communication with up to 128
>> drives. I'm thinking about having ~8-16 drives on each controller
>> (PCI-e card) so I think I want option 3. Additionally, because I might
>> get greedier in the future and decide to add more drives on each
>> controller I think option 3 is the best way to go. I can have a
>> motherboard with a lot of PCIe slots and have one controller card for
>> each expander.
>> 
>> 
>> Cases like the Supermicro 846E1-R900B have 24 hot swap bays accessible
>> via a single (4u) LSI SASX36 SAS expander chip, but I'm worried about
>> controller death and having the backplane as a single point of failure.
>> 
>> I guess, ideally, I'd like a 4u enclosure with 2x2u SAS expanders. If
>> I wanted hardware redundancy, I could then use mirrored vdevs with one
>> side of each  mirror on one controller/expander pair and the other
>> side on a separate pair. This would allow me to survive controller or
>> expander death as well hard drive failure.
>> 
>> 
>> Replace motherboard: ~500
>> Replace backplane: ~500
>> Replace controller: ~300
>> Replace disk (SATA): ~100
>> 
>> 
>> Does anyone have any example systems they have built or any thoughts
>> on what I could do differently?
>> 
>> Best regards,
>>Ian.
>> 
>> 
>> [1] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg27234.html
>> [2] http://www.avsforum.com/avs-vb/showthread.php?p=17543496
>> [3] http://www.stringliterals.com/?p=53
>> [4] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg22761.html
>> 
>> 
>> ___
>> 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] ZFS storage server hardware

[Bruno Sousa]

Hi,

I currently have a 1U server (Sun X2200) with 2 LSI HBA attached to a
Supermicro JBOD chassis each one with 24 disks , SATA 1TB, and so far so
good..
So i have a 48 TB raw capacity, with a mirror configuration for NFS
usage (Xen VMs) and i feel that for the price i paid i have a very nice 
system.


Bruno

Ian Allison wrote:
> Hi,
>
> I know (from the zfs-discuss archives and other places [1,2,3,4]) that
> a lot of people are looking to use zfs as a storage server in the
> 10-100TB range.
>
> I'm in the same boat, but I've found that hardware choice is the
> biggest issue. I'm struggling to find something which will work nicely
> under solaris and which meets my expectations in terms of hardware.
> Because of the compatibility issues, I though I should ask here to see
> what solutions people have already found.
>
>
> I'm learning as I go here, but as far as I've been able to determine,
> the basic choices for attaching drives seem to be
>
> 1) SATA Port multipliers
> 2) SAS Multilane Enclosures
> 3) SAS Expanders
>
> In option 1, the controller can only talk to one device at a time, in
> option 2 each miniSAS connector can talk to 4 drives at a time but in
> option 3 the expander can allow for communication with up to 128
> drives. I'm thinking about having ~8-16 drives on each controller
> (PCI-e card) so I think I want option 3. Additionally, because I might
> get greedier in the future and decide to add more drives on each
> controller I think option 3 is the best way to go. I can have a
> motherboard with a lot of PCIe slots and have one controller card for
> each expander.
>
>
> Cases like the Supermicro 846E1-R900B have 24 hot swap bays accessible
> via a single (4u) LSI SASX36 SAS expander chip, but I'm worried about
> controller death and having the backplane as a single point of failure.
>
> I guess, ideally, I'd like a 4u enclosure with 2x2u SAS expanders. If
> I wanted hardware redundancy, I could then use mirrored vdevs with one
> side of each  mirror on one controller/expander pair and the other
> side on a separate pair. This would allow me to survive controller or
> expander death as well hard drive failure.
>
>
> Replace motherboard: ~500
> Replace backplane: ~500
> Replace controller: ~300
> Replace disk (SATA): ~100
>
>
> Does anyone have any example systems they have built or any thoughts
> on what I could do differently?
>
> Best regards,
> Ian.
>
>
> [1] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg27234.html
> [2] http://www.avsforum.com/avs-vb/showthread.php?p=17543496
> [3] http://www.stringliterals.com/?p=53
> [4] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg22761.html
>
>
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] ZFS storage server hardware

[Richard Elling]

On Nov 17, 2009, at 12:50 PM, Ian Allison wrote:


Hi,

I know (from the zfs-discuss archives and other places [1,2,3,4])  
that a lot of people are looking to use zfs as a storage server in  
the 10-100TB range.


I'm in the same boat, but I've found that hardware choice is the  
biggest issue. I'm struggling to find something which will work  
nicely under solaris and which meets my expectations in terms of  
hardware. Because of the compatibility issues, I though I should ask  
here to see what solutions people have already found.



I'm learning as I go here, but as far as I've been able to  
determine, the basic choices for attaching drives seem to be


1) SATA Port multipliers
2) SAS Multilane Enclosures
3) SAS Expanders

In option 1, the controller can only talk to one device at a time,  
in option 2 each miniSAS connector can talk to 4 drives at a time  
but in option 3 the expander can allow for communication with up to  
128 drives. I'm thinking about having ~8-16 drives on each  
controller (PCI-e card) so I think I want option 3. Additionally,  
because I might get greedier in the future and decide to add more  
drives on each controller I think option 3 is the best way to go. I  
can have a motherboard with a lot of PCIe slots and have one  
controller card for each expander.



Cases like the Supermicro 846E1-R900B have 24 hot swap bays  
accessible via a single (4u) LSI SASX36 SAS expander chip, but I'm  
worried about controller death and having the backplane as a single  
point of failure.


There will be dozens of single point failures in your system.  Don't  
worry about
controllers or expanders because they will be at least 10x more  
reliable than
your disks.  If you want to invest for better reliability, invest in  
enterprise class

disks, preferably SSDs.
 -- richard



I guess, ideally, I'd like a 4u enclosure with 2x2u SAS expanders.  
If I wanted hardware redundancy, I could then use mirrored vdevs  
with one side of each  mirror on one controller/expander pair and  
the other side on a separate pair. This would allow me to survive  
controller or expander death as well hard drive failure.



Replace motherboard: ~500
Replace backplane: ~500
Replace controller: ~300
Replace disk (SATA): ~100


Does anyone have any example systems they have built or any thoughts  
on what I could do differently?


Best regards,
Ian.


[1] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg27234.html
[2] http://www.avsforum.com/avs-vb/showthread.php?p=17543496
[3] http://www.stringliterals.com/?p=53
[4] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg22761.html


___
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] ZFS storage server hardware

[Ian Allison]

Hi,

I know (from the zfs-discuss archives and other places [1,2,3,4]) that a 
lot of people are looking to use zfs as a storage server in the 10-100TB 
range.


I'm in the same boat, but I've found that hardware choice is the biggest 
issue. I'm struggling to find something which will work nicely under 
solaris and which meets my expectations in terms of hardware. Because of 
the compatibility issues, I though I should ask here to see what 
solutions people have already found.



I'm learning as I go here, but as far as I've been able to determine, 
the basic choices for attaching drives seem to be


1) SATA Port multipliers
2) SAS Multilane Enclosures
3) SAS Expanders

In option 1, the controller can only talk to one device at a time, in 
option 2 each miniSAS connector can talk to 4 drives at a time but in 
option 3 the expander can allow for communication with up to 128 drives. 
I'm thinking about having ~8-16 drives on each controller (PCI-e card) 
so I think I want option 3. Additionally, because I might get greedier 
in the future and decide to add more drives on each controller I think 
option 3 is the best way to go. I can have a motherboard with a lot of 
PCIe slots and have one controller card for each expander.



Cases like the Supermicro 846E1-R900B have 24 hot swap bays accessible 
via a single (4u) LSI SASX36 SAS expander chip, but I'm worried about 
controller death and having the backplane as a single point of failure.


I guess, ideally, I'd like a 4u enclosure with 2x2u SAS expanders. If I 
wanted hardware redundancy, I could then use mirrored vdevs with one 
side of each  mirror on one controller/expander pair and the other side 
on a separate pair. This would allow me to survive controller or 
expander death as well hard drive failure.



Replace motherboard: ~500
Replace backplane: ~500
Replace controller: ~300
Replace disk (SATA): ~100


Does anyone have any example systems they have built or any thoughts on 
what I could do differently?


Best regards,
Ian.


[1] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg27234.html
[2] http://www.avsforum.com/avs-vb/showthread.php?p=17543496
[3] http://www.stringliterals.com/?p=53
[4] http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg22761.html


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

Re: [zfs-discuss] Old zfs version with OpenSolaris 2009.06 JeOS ??

[Benoit Heroux]

Hi Tim,

You were right.  I wasn't using the dev repository, so i was stuck into an old 
build of zfs.

So i did those step:
- pkg set-publisher -P -O http://pkg.opensolaris.org/dev/ opensolaris.org
- pkg image-update -v : download and upgrade.
- reboot

Then i have version 4 now of zfs and version 19 of zpool.

And the release is now:
$ cat /etc/release
   OpenSolaris Development snv_127 X86
   Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
Use is subject to license terms.
   Assembled 06 November 2009

Thanks a lot.

So i learn that the release at 
http://hub.opensolaris.org/bin/view/Project+jeos/200906+Prototype#HDownloads is 
pretty old and need to be updated :)
-- 
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] [Fwd: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion in snv 128]

[Craig S. Bell]

I don't have any problem with a rewrite, but please allow a non-GUI-dependent 
solution for headless servers.  Also please add rsync as an option, rather than 
replacing zfs send/recv.   Thanks.
-- 
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] Comstar thin provisioning space reclamation

[Ed Plese]

You can reclaim this space with the SDelete utility from Microsoft.
With the -c option it will zero any free space on the volume.  For
example:

C:\>sdelete -c C:

I've tested this with xVM and with compression enabled for the zvol,
but it worked very well.


Ed Plese


On Tue, Nov 17, 2009 at 12:13 PM, Brent Jones  wrote:
> I use several file-backed thin provisioned iSCSI volumes presented over 
> Comstar.
> The initiators are Windows 2003/2008 systems with the MS MPIO initiator.
>
> The Windows systems only claim to be using about 4TB of space, but the
> ZFS volume says 7.12TB is used.
> Granted, I imagine ZFS allocates the blocks as soon as Windows needs
> space, and Windows will eventually not need that space again.
> Is there a way to reclaim un-used space on a thin provisioned iSCSI target?
>
>
>
> --
> Brent Jones
> br...@servuhome.net
> ___
> 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] Comstar thin provisioning space reclamation

[Brent Jones]

I use several file-backed thin provisioned iSCSI volumes presented over Comstar.
The initiators are Windows 2003/2008 systems with the MS MPIO initiator.

The Windows systems only claim to be using about 4TB of space, but the
ZFS volume says 7.12TB is used.
Granted, I imagine ZFS allocates the blocks as soon as Windows needs
space, and Windows will eventually not need that space again.
Is there a way to reclaim un-used space on a thin provisioned iSCSI target?



-- 
Brent Jones
br...@servuhome.net
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] updated zfs on disk format?

[Richard Elling]

On Nov 17, 2009, at 8:06 AM, Cindy Swearingen wrote:


Hi Luca,

We do not have an updated version of this document.


One of the nice features of the ZFS design is that new capabilities  
can be
added without changing the on disk format as described in  
ondiskformat0822.pdf.
For instance, if a new name-value pair is added as part of a feature,  
the
coders may say it is a new on disk format change, and bump the zpool  
version.

But the on disk format as described in the ondiskformat0822.pdf does not
change.  IMHO, the community will be better served by not overloading  
the

term "on disk format."
 -- richard



Thanks,

Cindy

On 11/17/09 06:59, Luca Morettoni wrote:
Hi see the "ondiskformat" PDF[1] is "quite" old, there is an  
updated version of that important document?

Thanks!!
[1]http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf

___
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] Disk I/O in RAID-Z as new disks are added/removed

[Bob Friesenhahn]

On Sun, 15 Nov 2009, Joe Auty wrote:


I've see several comparisons to existing RAID solutions, but I'm not finding 
whether the more
disks you add, the more I/O you can get, unless I'm missing something?


Perhaps that is because "it depends" and you may or may not get "more 
I/O", depending on what "more I/O" means to you.


In some cases the I/O rates depend on decision-making in the zfs code. 
For example, while huge sequential I/O rates may be available, the zfs 
code might decide to ramp-up the prefetch rate over time so that you 
only see the huge rate for very large files.  The algorithms and 
decisions in zfs tend to change over time based on bug reports and the 
zfs implementor's accumlated experience.


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] updated zfs on disk format?

[Cindy Swearingen]

Hi Luca,

We do not have an updated version of this document.

Thanks,

Cindy

On 11/17/09 06:59, Luca Morettoni wrote:
Hi see the "ondiskformat" PDF[1] is "quite" old, there is an updated 
version of that important document?


Thanks!!

[1]http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf 


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

[zfs-discuss] updated zfs on disk format?

[Luca Morettoni]

Hi see the "ondiskformat" PDF[1] is "quite" old, there is an updated 
version of that important document?


Thanks!!

[1]http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf
--
Luca Morettoni  | OpenSolaris SCA #OS0344
Web/BLOG: http://www.morettoni.net/ | http://twitter.com/morettoni
jugUmbria founder - https://jugUmbria.dev.java.net/
ITL-OSUG leader - http://www.opensolaris.org/os/project/itl-osug/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Disk I/O in RAID-Z as new disks are added/removed

[Joe Auty]

Tim Cook wrote:
> On Sun, Nov 15, 2009 at 2:57 AM, besson3c  > wrote:
>
> Anybody?
>
> I would truly appreciate some general, if not definite insight as
> to what one can expect in terms of I/O performance after adding
> new disks to ZFS pools.
>
>
>  
> I'm guessing you didn't get a response because the first result on
> google should have the answer you're looking for.  In any case, if
> memory serves correctly, Jeff's blog should have all the info you need:
> http://blogs.sun.com/bonwick/entry/raid_z
>
>
Hey Tim,

I have seen and read that page several times before and after writing this.

I've see several comparisons to existing RAID solutions, but I'm not
finding whether the more disks you add, the more I/O you can get, unless
I'm missing something?


> --Tim


-- 
Joe Auty
NetMusician: web publishing software for musicians
http://www.netmusician.org
j...@netmusician.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] [Fwd: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion in snv 128]

[Tim Foster]

Hi all,

Just forwarding Niall's heads-up message about the impending removal of
the existing zfs-auto-snapshot implementation in nv_128

I've not been involved in the rewrite, but what I've read about the new
code, it'll be a lot more efficient than the old ksh-based code, and
will fix many of the problems with the old solution.

The new code currently lacks support for the 'zfs/backup' functionality
- which allowed you to specify a command to tell the service to generate
incremental or full send streams at each time interval, along with a
commandline to process that stream (sshing to a remote server and doing
a zfs recv, for example)

If you do use that functionality, it'd be good to drop a mail to the
thread[1] on the zfs-auto-snapshot alias.


It's been a wild ride, but my work on zfs-auto-snapshot is done I
think :-)

cheers,
tim

[1] 
http://mail.opensolaris.org/pipermail/zfs-auto-snapshot/2009-November/thread.html#199

 Forwarded Message 
From: Niall Power 
To: zfs-auto-snaps...@opensolaris.org
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
in  snv 128
Date: Mon, 16 Nov 2009 18:26:28 +1100

This is a heads up for user of Tim's zfs-auto-snapshot auto snapshot 
service currently delivered
in Solaris Nevada and OpenSolaris. As of build 128 the zfs-auto-snapshot 
scripts are being replaced
by a rewritten daemon (time-sliderd).
Time-sliderd will continue to support the existing SMF 
auto-snapshot: service instances
as it's configuration mechanism so for most users there should be no 
significant differences noticeable.
Some of the options will no longer be supported however since they are 
either obsolete or too
specifically tied to the zfs-auto-snapshot implementation to make them 
portable.

Stuff that will work:
- Default out of the box schedules (frequent, hourly, daily, weekly, 
monthly)
- Custom schedules

SMF properties that will be supported:
- interval
- period
- keep

SMF properties that won't be supported
- "offset" The time-slider daemon schedules snapshots based on relative
   times rather that absolute times which makes it more suitable for systems
   that do not have constant 24/7 uptime so this feature isn't so relevant
   anymore (it only got implemented recently in zfs-auto-snapshot also)

- "label" Dropping it allows naming shemes to be simplified and
   enforces uniqueness when SMF tries to import an auto-snapshot instance

- backup/backup-save-cmd/backup-lock
  We plan to implement an rsync based backup mechanism that allows backups
  to be browsed like a proper filesystem instead of having binary 
snapshot blobs
  that are explicitly classified as unstable/volatile by zfs(1)

For those who want to use time-slider without going through the GUI, simply
enable/configure (or create) the auto-snapshot instances you need then 
enable
the time-slider SMF service. time-slider will pick up the enabled 
auto-snapshot
instances and schedule snapshots for them.

For folks who prefer to continue using zfs-auto-snapshot, you will need to
remove SUNWgnome-time-slider and install the existing zfs-auto-snapshot
packages instead.

Comments/questions welcome ;)

Cheers,
Niall.

___
zfs-auto-snapshot mailing list
zfs-auto-snaps...@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot


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

Re: [zfs-discuss] Best config for different sized disks

[Erik Trimble]

Tim Cook wrote:



On Mon, Nov 16, 2009 at 12:09 PM, Bob Friesenhahn 
mailto:bfrie...@simple.dallas.tx.us>> 
wrote:


On Sun, 15 Nov 2009, Tim Cook wrote:


Once again I question why you're wasting your time with
raid-z.  You might as well just stripe across all the drives. 
You're taking a performance penalty for a setup that

essentially has 0 redundancy.  You lose a 500gb drive, you
lose everything.


Why do you say that this user will lose everything?  The two
concatenated/striped devices on the local system are no different
than if they were concatenated on SAN array and made available as
one LUN. If one of those two drives fails, then it would have the
same effect as if one larger drive failed.

Bob


Can I blame it on too many beers?  I was thinking losing half of one 
drive, rather than an entire vdev would just cause "weirdness" in the 
pool, rather than a clean failure.  I suppose without experimentation 
there's no way to really no, in theory though, zfs should be able to 
handle it.


--Tim

Back to the original question:  the "concat using SVM" method works OK 
if the disk you have are all integer multiples of each other (that is, 
this worked because he had 2 500GB drives to make a 1TB drive out of).  
It certainly seems the best method - both for performance and maximum 
disk space - that I can think of.   However, it won't work well in other 
cases:  i.e.  a couple of 250GB drives, and a couple of 1.5TB drives.


In cases of serious mis-match between the drive sizes, especially when 
there's not a real good way to concat to get a metadrive big enough to 
match others, I'd recommend going for multiple zpools, and slicing up 
the bigger drives to allow for RAIDZ-ing with the smaller ones "natively".


E.g.

let's say you have 3 250GB drives, and 3 1.5TB drives. You could 
partition the 1.5TB drives into 250GB and 1.25TB partitions, and then 
RAIDZ the 3 250GB drives together, plus the 250GB partitions as one 
zpool, then the 1.25TB partitions as another zpool.


You'll have some problems with contending I/O if you try to write to 
both zpools at once, but it's the best way I can think of to maximize 
space and at the same time maximize performance for single-pool I/O.


I think it would be a serious performance mistake to combine the two 
pools as vdevs in a single pool, though it's perfectly possible.


I.e.
(preferred)
zpool create smalltank raidz c0t0d0 c0t1d0 c0t2d0 c1t0d0s0 c1t1d0s0 c1t2d0s0
zpool create largetank raidz c1t0d0s1 c1t1d0s1 c1t2d0s1

instead of

zpool create supertank raidz c0t0d0 c0t1d0 c0t2d0 c1t0d0s0 c1t1d0s0 
c1t2d0s0 raidz c1t0d0s1 c1t1d0s1 c1t2d0s1




--
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

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