date:20100326

Re: [zfs-discuss] SSD As ARC

2010-03-26 Thread Muhammed Syyid

Which is why I was looking to setup 
1x8 raidz2 as pool1
and
1x8 raidz2 as pool2

instead of as two vdevs under 1 pool. That way I can have 'some' flexibility 
where I could take down pool1 or pool2 without affecting the other.

The issue I had was how do I set up an L2ARC for 2 pools (pool1/pool2) using 1 
SSD drive
-- 
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] Mixed ZFS vdev in same pool.

2010-03-26 Thread Erik Trimble

Justin wrote:

I have a question about using mixed vdev in the same zpool and what the
community opinion is on the matter. Here is my setup:

I have four 1TB drives and two 500GB drives. When I first setup ZFS I was
under the assumption that it does not really care much on how you add devices
to the pool and it assumes you are thinking things through. But when I tried
to create a pool (called group) with four 1TB disk in raidz and two 500GB disk
in mirror configuration to the same pool ZFS complained and said if I wanted to
do it I had to add a -f (which I assume stands for force). So was ZFS
attempting to stop me from doing something generally considered bad?

Were any of these drives previous part of another pool? As such, ZFS
will usually complain if it finds a signature already on the drive, and
make you use the '-f' option. Otherwise, I don't /think/ it should care
if you are being foolish.

Some other questions I have, lets assume that this setup isn't that bad (or it
is that bad and these questions will be why):

If one 500GB disk dies (c10dX) in the mirror and I choose not to replace it, would I be able to migrate the files that are on the other mirror that still works over to the drives in the raidz configuration assuming there is space? Would ZFS inform me which files are affected, like it does in other situations?

No, you can't currently. Essentially what you are asking is if you can
remove the mirror from the pool - this is not currently possible, though
I'm hopeful it may happen in the not-so-distant future.

In this configuration how does Solaris/ZFS determine which vdev to place the
current write operations worth of data into?

It will attempt to balance the data across the two vdevs (the mirror and
raidz) until it runs out of space on one (in your case, the mirror
pair). ZFS does not currently understand differences in underlying
hardware performance or vdev layout, so it can't "magically" decide to
write data to one particular vdev over the other. In fact, I can't
really come up with a sane way to approach that problem - there are
simply too many variables to allow for automagic optimization like
that. Perhaps if there was some way to "hint" to ZFS upon pool creation
like "perfer vdev A for large writes, vdev B for small writes", but even
so, I think that's marching off into a wilderness we don't want to
visit, let alone spend any time in.

I would consider this a poor design, as the vdevs have very different
performance profiles, which hurts the overall performance of the pool
significantly.

Is there any situations where data would, for some reason, not be protected against single disk failures?

No. In your config, both vdevs can survive a single disk failure, so the
pool is fine.
Would this configuration survive a two disk failure if the disk are in a separate vdev?

Yes.

jsm...@corax:~# zpool status group
pool: group
state: ONLINE
scrub: none requested
config:

NAMESTATE READ WRITE CKSUM
group ONLINE 0 0 0
..raidz1ONLINE 0 0 0
c7t0d0 ONLINE 0 0 0
c7t1d0 ONLINE 0 0 0
c8t0d0 ONLINE 0 0 0
c8t1d0 ONLINE 0 0 0
..mirrorONLINE 0 0 0
c10d0 ONLINE 0 0 0
c10d1 ONLINE 0 0 0

errors: No known data errors
jsm...@corax:~# zfs list group
NAMEUSED AVAIL REFER MOUNTPOINT
group 94.4K 3.12T 23.7K /group

This isn't for a production environment in some datacenter but nevertheless I
would like to make the data as reasonably secure as possible while maximizing
total storage space.

If you are using Solaris (which you seem to be doing), my recommendation
is that you use SVM to create a single 1TB concat device from the 2
500GB drives, then use that 1TB concat device along with the other
physical 1TB devices to create your pool with. Failing 1 500GB drive
then invalidates that concat device, which ZFS assumes is a single
"disk", and behaves accordingly.

Thus, my suggestion is something like this:

( using your cX layout in the example above)

# metainit d0 2 1 c10d0s2 1 c10d1s2
# zpool create tank raidz c7t0d0 c7t1d0 c8t0d0 c8t1d0 /dev/md/dsk/d0

This would get you a RAIDZ of capacity 4TB or thereabouts, able to
survive 1 disk failure (or, both 500GB drives failing)

--
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] Mixed ZFS vdev in same pool.

2010-03-26 Thread Justin

I have a question about using mixed vdev in the same zpool and what the 
community opinion is on the matter.  Here is my setup:

I have four 1TB drives and two 500GB drives.  When I first setup ZFS I was 
under the assumption that it does not really care much on how you add devices 
to the pool and it assumes you are thinking things through.  But when I tried 
to create a pool (called group) with four 1TB disk in raidz and two 500GB disk 
in mirror configuration to the same pool ZFS complained and said if I wanted to 
do it I had to add a -f (which I assume stands for force).  So was ZFS 
attempting to stop me from doing something generally considered bad?

Some other questions I have, lets assume that this setup isn't that bad (or it 
is that bad and these questions will be why):

If one 500GB disk dies (c10dX) in the mirror and I choose not to replace it, 
would I be able to migrate the files that are on the other mirror that still 
works over to the drives in the raidz configuration assuming there is space?  
Would ZFS inform me which files are affected, like it does in other situations? 

In this configuration how does Solaris/ZFS determine which vdev to place the 
current write operations worth of data  into?

Is there any situations where data would, for some reason, not be protected 
against single disk failures? 

Would this configuration survive a two disk failure if the disk are in a 
separate vdev? 


jsm...@corax:~# zpool status group
  pool: group
 state: ONLINE
 scrub: none requested
config:

NAMESTATE READ WRITE CKSUM
group   ONLINE   0 0 0
..raidz1ONLINE   0 0 0
c7t0d0  ONLINE   0 0 0
c7t1d0  ONLINE   0 0 0
c8t0d0  ONLINE   0 0 0
c8t1d0  ONLINE   0 0 0
  ..mirrorONLINE   0 0 0
  c10d0   ONLINE   0 0 0
  c10d1   ONLINE   0 0 0

errors: No known data errors
jsm...@corax:~# zfs list group
NAMEUSED  AVAIL  REFER  MOUNTPOINT
group  94.4K  3.12T  23.7K  /group


This isn't for a production environment in some datacenter but nevertheless I 
would like to make the data as reasonably secure as possible while maximizing 
total storage space.
-- 
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 and 4kb sector Drives (All new western digital GREEN Drives?)

2010-03-26 Thread Darren Mackay

For the time being, the EARS series of drives actually present 512 byte sectors 
to the o/s through emulation in firmware.

The drive I tested was WD20EARS (2TB WD Caviar Green Advanced Format drives):

MDL: WD20EARS-00S81
DATE: 29 DEC 2009
DCM: HBRNHT2BB
DCX: 6019S1W87
LBA: 3907029168

The LBA above is key -. this s the unmber of sectors presented by the drive's 
firmware to the host o/s. Combinations of jumpers, and runnign the WD alignment 
utility only appears to reorganise how the ECC is stored in 4k blocks 
physically on disk, but the drive still presents each 4K physicaly dick block 
as 8 x 512byte logical blocks to the host.

I have logged a support request with WD to see if they may be releasing 
firmware that will present the 4k blocks natively. As an individual user, i 
actually doubt that WD will ever respond. I can only hope that quite a few 
others (00's / 000's) of other people also log similar requests and that WD may 
release appropriate firmware.

Would be grateful to hear of any others and their testing experiences with 
other series of advanced format drives from WD.

The drives works perfectly on 64bit kernel, but not on 32bit osol kernels. I 
purchased the drive just to test on 32bit kernel - mainly as there are quite a 
lot of soho NAS devices that may be able to use our Velitium Embedded Kit for 
OpenSolaris with drives larger than 1TB. 

It would be nice if the 32bit osol kernel support 48bit LBA (similar to linux, 
not sure if 32bit BSD supports 48bit LBA ), then the drive would probably work 
- perhaps later in the year we will have time to work on a patch to support 
48bit lba on the 32bit osol kernels...

Darren Mackay
http://www.sikkra.com
http://sourceforge.net/projects/velitium/
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

68 matches

Mail list logo