Re: [zfs-discuss] Best layout for 15 disks?

[mike]

see, originally when i read about zfs it said it could expand to petabytes or 
something. but really, that's not as a single "filesystem" ? that could only be 
accomplished through combinations of pools?

i don't really want to have to even think about managing two separate 
"partitions" - i'd like to group everything together into one large 13tb 
instance (or however big it winds up being) - is that not possible?
 
 
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] error found while scubbing, how to fix it?

[Luca Morettoni]

On 08/21/08 17:45, Jürgen Keil wrote:
> The bug happens with unmounted filesystems, so you
> need to mount them first, then umount.

thanks, now all result are fine!!!

# zpool status -v
   pool: rpool
  state: ONLINE
  scrub: scrub completed after 0h29m with 0 errors on Fri Aug 22 
09:11:30 2008
config:

NAMESTATE READ WRITE CKSUM
rpool   ONLINE   0 0 0
  c5t0d0s0  ONLINE   0 0 0

errors: No known data errors

bye!
-- 
Luca Morettoni  - http://morettoni.net
GPG key 0xD69411BB: C329 AED4 5923 1982 6F12  3036 B51E 664F D694 11BB
jugUmbria founder - https://jugUmbria.dev.java.net/ | Thawte notary
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] Best layout for 15 disks?

[Claus Guttesen]

> see, originally when i read about zfs it said it could expand to petabytes or 
> something. but really, that's not as a single "filesystem" ? that could only 
> be accomplished through combinations of pools?
>
> i don't really want to have to even think about managing two separate 
> "partitions" - i'd like to group everything together into one large 13tb 
> instance (or however big it winds up being) - is that not possible?

You could try

zpool create my_disk \
  raidz disk1 disk2 disk3 disk4 disk5 \
  raidz disk6 disk7 disk8 disk9 disk10 \
  raidz disk11 disk12 disk13 disk14 disk15 \
  spare disk16

This will give you 12 (metric) TB which is almost 11 TB as seen by the computer.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentlest gamester is the soonest winner.

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

Re: [zfs-discuss] Best layout for 15 disks?

[Peter Tribble]

On Fri, Aug 22, 2008 at 8:11 AM, mike <[EMAIL PROTECTED]> wrote:
> see, originally when i read about zfs it said it could expand to petabytes or 
> something. but really, that's not as a single "filesystem" ? that could only 
> be accomplished through combinations of pools?
>
> i don't really want to have to even think about managing two separate 
> "partitions" - i'd like to group everything together into one large 13tb 
> instance (or however big it winds up being) - is that not possible?

Sure it's possible. That's how it works. Say with 16 disks:

zpool create tank raidz1 disk1 disk2 disk3 disk4 disk5 \
  raidz1 disk6 disk7 disk8 disk9 disk10 \
  raidz1 disk11 disk12 disk13 disk14 disk15 \
  spare disk16

Gives you a single pool containing 3 raidz vdevs (each 4 data + 1 parity)
and a hot spare.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[Robert Milkowski]

Hello mike,

Friday, August 22, 2008, 8:11:36 AM, you wrote:

m> see, originally when i read about zfs it said it could expand to
m> petabytes or something. but really, that's not as a single
m> "filesystem" ? that could only be accomplished through combinations of pools?

m> i don't really want to have to even think about managing two
m> separate "partitions" - i'd like to group everything together into
m> one large 13tb instance (or however big it winds up being) - is that not 
possible?


you can do something like:

zpool create test raidz2 d1 d2 d3 d4 d5 raidz2 d6 d7 d8 d9 d10 \
  raidz2 d11 d12 d13 d14 d15

zfs create test/fs1
zfs create test/fs2
zfs create test/fs3


That way you have created a pool which is made of 3 raid-z2 groups and
you have then created additional 3 file systems withint the pools,
each of them can use all space in a pool by default.

Later on you can do:

  zpool add test raidz2 d16 d17 d18 d19 d20





-- 
Best regards,
 Robert Milkowskimailto:[EMAIL PROTECTED]
   http://milek.blogspot.com

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

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

likewise i could also do something like

zpool create tank raidz1 disk1 disk2 disk3 disk4 disk5 disk6 disk7 \
raidz1 disk8 disk9 disk10 disk11 disk12 disk13 disk14 disk15

and i'd have a 7 disk raidz1 and an 8 disk raidz1... and i'd have 15 disks 
still broken up into not-too-horrible pool sizes and a single filesystem to 
use, if i understood everything.

either pool could suffer one physical failure. i run "fmadm faulty" every 10 
minutes to notify me instantly of any detected failures/events (thanks Richard 
for the pointers :))
 
 
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] Best layout for 15 disks?

[Darren J Moffat]

mike wrote:
> likewise i could also do something like
> 
> zpool create tank raidz1 disk1 disk2 disk3 disk4 disk5 disk6 disk7 \
> raidz1 disk8 disk9 disk10 disk11 disk12 disk13 disk14 disk15
> 
> and i'd have a 7 disk raidz1 and an 8 disk raidz1... and i'd have 15 disks 
> still broken up into not-too-horrible pool sizes and a single filesystem to 
> use, if i understood everything.
> 
> either pool could suffer one physical failure. i run "fmadm faulty" every 10 
> minutes to notify me instantly of any detected failures/events (thanks 
> Richard for the pointers :))
  

vdev not pool.  There is only one pool and thus one filesystem namespace 
in that configuration.

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

[zfs-discuss] zpool import hangs

[Erik Gulliksson]

Hi,

I have a zfs-pool (unfortunately not setup according to the Best
Practices Guide) that somehow got corrupted after a spontaneous server
reboot. On Solaris 10u4 the machine simply panics when I try to import
the pool. So what I've done is taken a dd-image of the whole LUN so
that I have something to lab with without breaking original data. Then
I've installed Solaris Express b95 (in a virtual machine) and made the
disk image visible via iSCSI. This in hope that the newer zfs-code in
b95 would be able to import the pool.

Here is the output of some hopefully relevant commands to you zfs-gurus :)

bash-3.2# zpool import
 pool: data1
   id: 16337833607404088147
 state: ONLINE
status: The pool is formatted using an older on-disk version.
action: The pool can be imported using its name or numeric identifier, though
   some features will not be available without an explicit 'zpool upgrade'.
config:
   data1  ONLINE
 c2t2d0ONLINE

bash-3.2# zpool import data1
cannot import 'data1': pool may be in use from other system
use '-f' to import anyway

bash-3.2# zpool import -f data1
(when sniffing the iscsi-traffic there is an initial burst of requests
and data, but then the command zpool hangs forever and can't even be
kill-9'd)

bash-3.2# zdb -l /dev/rdsk/c2t2d0s0

LABEL 0

   version=3
   name='data1'
   state=0
   txg=696136211
   pool_guid=16337833607404088147
   top_guid=8756997626625498593
   guid=8756997626625498593
   vdev_tree
   type='disk'
   id=0
   guid=8756997626625498593
   path='/dev/dsk/c6t213d0s0'
   devid='id1,[EMAIL PROTECTED]/a'
   whole_disk=1
   metaslab_array=13
   metaslab_shift=35
   ashift=9
   asize=6499480109056
   DTL=17
(3 more labels with same content follows here)

bash-3.2# zdb -uuu -e data1
Uberblock
magic = 00bab10c
version = 3
txg = 698279317
guid_sum = 6648087160320035124
timestamp = 1214932560 UTC = Tue Jul  1 19:16:00 2008
rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:5680200:200>
DVA[1]=<0:320200:200> DVA[2]=<0:4881800:200> fletcher4 lzjb LE
contiguous birth=698279317 fill=189
cksum=89744d6d8:36e7cf71f81:b1d06b2acd36:1850b4cc5621f3

I have also tried to blindly execute the commands described by
signature kangurek in
 but
without success.

Without about knowing much about zfs, I couldn't help but notice that
the txg ids differs in the label and uberblock. Is this normal?

Any help on moving forward with this recovery process is much appreciated!

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

Re: [zfs-discuss] zpool import hangs

[Victor Latushkin]

Hi Erik,

Erik Gulliksson wrote:
> Hi,
> 
> I have a zfs-pool (unfortunately not setup according to the Best
> Practices Guide) that somehow got corrupted after a spontaneous server
> reboot. On Solaris 10u4 the machine simply panics when I try to import
> the pool.

Panic stack would be useful.

> So what I've done is taken a dd-image of the whole LUN so
> that I have something to lab with without breaking original data. Then
> I've installed Solaris Express b95 (in a virtual machine) and made the
> disk image visible via iSCSI. This in hope that the newer zfs-code in
> b95 would be able to import the pool.
> 
> Here is the output of some hopefully relevant commands to you zfs-gurus :)
> 
> bash-3.2# zpool import
>  pool: data1
>id: 16337833607404088147
>  state: ONLINE
> status: The pool is formatted using an older on-disk version.
> action: The pool can be imported using its name or numeric identifier, though
>some features will not be available without an explicit 'zpool 
> upgrade'.
> config:
>data1  ONLINE
>  c2t2d0ONLINE
> 
> bash-3.2# zpool import data1
> cannot import 'data1': pool may be in use from other system
> use '-f' to import anyway
> 
> bash-3.2# zpool import -f data1
> (when sniffing the iscsi-traffic there is an initial burst of requests
> and data, but then the command zpool hangs forever and can't even be
> kill-9'd)

It is apparently blocked somewhere in kernel. Try to do something like 
this from another window to get better idea:

echo "::pid2proc|::walk thread|::findtsack -v" | mdb -k
echo "::threadlist -v" | mdb -k


Some useful information may be logged in FMA, try to see what is 
available there with

fmdump -eV

On Nevada you can try the following to  (same option repeated several 
times increases verbosity):

zdb -e -bb data1
zdb -e - data1

This may take a while on 6 Tb pool depending on how full it is...

> bash-3.2# zdb -l /dev/rdsk/c2t2d0s0
> 
> LABEL 0
> 
>version=3
>name='data1'
>state=0
>txg=696136211
>pool_guid=16337833607404088147
>top_guid=8756997626625498593
>guid=8756997626625498593
>vdev_tree
>type='disk'
>id=0
>guid=8756997626625498593
>path='/dev/dsk/c6t213d0s0'
>devid='id1,[EMAIL PROTECTED]/a'
>whole_disk=1
>metaslab_array=13
>metaslab_shift=35
>ashift=9
>asize=6499480109056
>DTL=17
> (3 more labels with same content follows here)
> 
> bash-3.2# zdb -uuu -e data1
> Uberblock
> magic = 00bab10c
> version = 3
> txg = 698279317
> guid_sum = 6648087160320035124
> timestamp = 1214932560 UTC = Tue Jul  1 19:16:00 2008
> rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:5680200:200>
> DVA[1]=<0:320200:200> DVA[2]=<0:4881800:200> fletcher4 lzjb LE
> contiguous birth=698279317 fill=189
> cksum=89744d6d8:36e7cf71f81:b1d06b2acd36:1850b4cc5621f3
> 
> I have also tried to blindly execute the commands described by
> signature kangurek in
>  but
> without success.
> 
> Without about knowing much about zfs, I couldn't help but notice that
> the txg ids differs in the label and uberblock. Is this normal?

Yes.

Btw, why does timestamp on your uberblock show July 1?

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

[zfs-discuss] Couple of ZFS panics...

[Ben Taylor]

I've got a Intel DP35DP Motherboard, Q6600 proc (Intel 2.4G, 4 core), 4GB of 
ram and a
copule of Sata disks, running ICH9.  S10U5, patched about a week ago or so...

I have a zpool on a single slice (haven't added a mirror yet, was getting to 
that) and have
started to suffer regular hard resets and have gotten a few panics.  The system 
is an 
nfs server for a couple of systems (not much write) and one writer (I do my svn 
updates
over NFS cause my ath0 board refuses to work in 64-bit on S10U5)  I also do 
local
builds on the same server.

Ideas?  

The first looks like:

panic[cpu0]/thread=9bcf0460: 
BAD TRAP: type=e (#pf Page fault) rp=fe80001739a0 addr=c064dba0


cmake: 
#pf Page fault
Bad kernel fault at addr=0xc064dba0
pid=6797, pc=0xf0a6350a, sp=0xfe8000173a90, eflags=0x10207
cr0: 80050033 cr4: 6f8
cr2: c064dba0 cr3: 12bf9b000 cr8: c
rdi: 6c60 rsi:0 rdx:0
rcx:0  r8: 8b21017f  r9: ae3a79c0
rax:0 rbx: c0611f40 rbp: fe8000173ac0
r10:0 r11:0 r12: ae4687d0
r13:   d8c200 r14:2 r15: 826c0480
fsb: 8000 gsb: fbc24ec0  ds:   43
 es:   43  fs:0  gs:  1c3
trp:e err:0 rip: f0a6350a
 cs:   28 rfl:10207 rsp: fe8000173a90
 ss:   30

fe80001738b0 unix:real_mode_end+71e1 ()
fe8000173990 unix:trap+5e6 ()
fe80001739a0 unix:_cmntrap+140 ()
fe8000173ac0 zfs:zio_buf_alloc+a ()
fe8000173af0 zfs:arc_buf_alloc+9f ()
fe8000173b70 zfs:arc_read+ee ()
fe8000173bf0 zfs:dbuf_read_impl+1a0 ()
fe8000173c30 zfs:zfsctl_ops_root+304172dd ()
fe8000173c60 zfs:dmu_tx_check_ioerr+6e ()
fe8000173cc0 zfs:dmu_tx_count_write+73 ()
fe8000173cf0 zfs:dmu_tx_hold_write+4a ()
fe8000173db0 zfs:zfs_write+1bb ()
fe8000173e00 genunix:fop_write+31 ()
fe8000173eb0 genunix:write+287 ()
fe8000173ec0 genunix:write32+e ()
fe8000173f10 unix:brand_sys_sysenter+1f2 ()

syncing file systems...
 3130
 15
 done
dumping to /dev/dsk/c0t0d0s1, offset 860356608, content: kernel
NOTICE: ahci_tran_reset_dport: port 0 reset port


The second liek this:

panic[cpu2]/thread=9b425f20: 
BAD TRAP: type=e (#pf Page fault) rp=fe80018cdf40 addr=c064dba0


nfsd: 
#pf Page fault
Bad kernel fault at addr=0xc064dba0
pid=665, pc=0xf0a6350a, sp=0xfe80018ce030, eflags=0x10207
cr0: 8005003b cr4: 6f8
cr2: c064dba0 cr3: 12a9df000 cr8: c
rdi: 6c60 rsi:0 rdx:0
rcx:0  r8: 8b21017f  r9:f
rax:0 rbx: c0611f40 rbp: fe80018ce060
r10:0 r11:0 r12: fe81c20ecf00
r13:   d8c200 r14:2 r15: 826c2240
fsb: 8000 gsb: 81a6c800  ds:   43
 es:   43  fs:0  gs:  1c3
trp:e err:0 rip: f0a6350a
 cs:   28 rfl:10207 rsp: fe80018ce030
 ss:   30

fe80018cde50 unix:real_mode_end+71e1 ()
fe80018cdf30 unix:trap+5e6 ()
fe80018cdf40 unix:_cmntrap+140 ()
fe80018ce060 zfs:zio_buf_alloc+a ()
fe80018ce090 zfs:arc_buf_alloc+9f ()
fe80018ce110 zfs:arc_read+ee ()
fe80018ce190 zfs:dbuf_read_impl+1a0 ()
fe80018ce1d0 zfs:zfsctl_ops_root+304172dd ()
fe80018ce200 zfs:dmu_tx_check_ioerr+6e ()
fe80018ce260 zfs:dmu_tx_count_write+73 ()
fe80018ce290 zfs:dmu_tx_hold_write+4a ()
fe80018ce350 zfs:zfs_write+1bb ()
fe80018ce3a0 genunix:fop_write+31 ()
fe80018ce410 nfssrv:do_io+b5 ()
fe80018ce610 nfssrv:rfs4_op_write+40e ()
fe80018ce770 nfssrv:rfs4_compound+1b3 ()
fe80018ce800 nfssrv:rfs4_dispatch+234 ()
fe80018ceb10 nfssrv:common_dispatch+88a ()
fe80018ceb20 nfssrv:nfs4_drc+3051ccc1 ()
fe80018cebf0 rpcmod:svc_getreq+209 ()
fe80018cec40 rpcmod:svc_run+124 ()
fe80018cec70 rpcmod:svc_do_run+88 ()
fe80018ceec0 nfs:nfssys+208 ()
fe80018cef10 unix:brand_sys_sysenter+1f2 ()

syncing file systems...
 done
dumping to /dev/dsk/c0t0d0s1, offset 860356608, content: kernel
NOTICE: ahci_tran_reset_dport: port 0 reset port
 
 
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] Best layout for 15 disks?

[Ross]

Hey Mike,

First of all, I'd strongly suggest going for raidz2 instead of raidz.  Dual 
parity protection is something I'd strongly recommended over single parity 
protection.

You also don't mention your boot pool.  You can't boot from a raid pool, so you 
need to put one disk aside for booting from.  You may have included that 
already though, so I'll assume you've got 15 data disks.

If you're not worried about performance you can probably create a single 15 
disk raidz2 pool.  In terms of data protection that's better than a 14 disk 
raidz pool with a hot spare, and gives you plenty of capacity.

As far as I'm aware, there's nothing stopping you creating a raidz or raidz2 
stripe of 15 disks, it's just that you get better performance with single digit 
stripe sizes.

Failing that, I'd suggest going for two raid-z2 stripes of 7 disks each, with 
one drive left over as a hot spare.

Ross
 
 
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] Couple of ZFS panics...

[Victor Latushkin]

Ben Taylor wrote:
> I've got a Intel DP35DP Motherboard, Q6600 proc (Intel 2.4G, 4 core), 4GB of 
> ram and a
> copule of Sata disks, running ICH9.  S10U5, patched about a week ago or so...
> 
> I have a zpool on a single slice (haven't added a mirror yet, was getting to 
> that) and have
> started to suffer regular hard resets and have gotten a few panics.  The 
> system is an 
> nfs server for a couple of systems (not much write) and one writer (I do my 
> svn updates
> over NFS cause my ath0 board refuses to work in 64-bit on S10U5)  I also do 
> local
> builds on the same server.
> 
> Ideas?  

Try to enable kmem_flags. zio_buf_buf() is very simple function calling
kmem_cache_alloc() in the end. I suspect some kind of kernel memory
corruption.

wbr,
victor

> The first looks like:
> 
> panic[cpu0]/thread=9bcf0460: 
> BAD TRAP: type=e (#pf Page fault) rp=fe80001739a0 addr=c064dba0
> 
> 
> cmake: 
> #pf Page fault
> Bad kernel fault at addr=0xc064dba0
> pid=6797, pc=0xf0a6350a, sp=0xfe8000173a90, eflags=0x10207
> cr0: 80050033 cr4: 6f8
> cr2: c064dba0 cr3: 12bf9b000 cr8: c
> rdi: 6c60 rsi:0 rdx:0
> rcx:0  r8: 8b21017f  r9: ae3a79c0
> rax:0 rbx: c0611f40 rbp: fe8000173ac0
> r10:0 r11:0 r12: ae4687d0
> r13:   d8c200 r14:2 r15: 826c0480
> fsb: 8000 gsb: fbc24ec0  ds:   43
>  es:   43  fs:0  gs:  1c3
> trp:e err:0 rip: f0a6350a
>  cs:   28 rfl:10207 rsp: fe8000173a90
>  ss:   30
> 
> fe80001738b0 unix:real_mode_end+71e1 ()
> fe8000173990 unix:trap+5e6 ()
> fe80001739a0 unix:_cmntrap+140 ()
> fe8000173ac0 zfs:zio_buf_alloc+a ()
> fe8000173af0 zfs:arc_buf_alloc+9f ()
> fe8000173b70 zfs:arc_read+ee ()
> fe8000173bf0 zfs:dbuf_read_impl+1a0 ()
> fe8000173c30 zfs:zfsctl_ops_root+304172dd ()
> fe8000173c60 zfs:dmu_tx_check_ioerr+6e ()
> fe8000173cc0 zfs:dmu_tx_count_write+73 ()
> fe8000173cf0 zfs:dmu_tx_hold_write+4a ()
> fe8000173db0 zfs:zfs_write+1bb ()
> fe8000173e00 genunix:fop_write+31 ()
> fe8000173eb0 genunix:write+287 ()
> fe8000173ec0 genunix:write32+e ()
> fe8000173f10 unix:brand_sys_sysenter+1f2 ()
> 
> syncing file systems...
>  3130
>  15
>  done
> dumping to /dev/dsk/c0t0d0s1, offset 860356608, content: kernel
> NOTICE: ahci_tran_reset_dport: port 0 reset port
> 
> 
> The second liek this:
> 
> panic[cpu2]/thread=9b425f20: 
> BAD TRAP: type=e (#pf Page fault) rp=fe80018cdf40 addr=c064dba0
> 
> 
> nfsd: 
> #pf Page fault
> Bad kernel fault at addr=0xc064dba0
> pid=665, pc=0xf0a6350a, sp=0xfe80018ce030, eflags=0x10207
> cr0: 8005003b cr4: 6f8
> cr2: c064dba0 cr3: 12a9df000 cr8: c
> rdi: 6c60 rsi:0 rdx:0
> rcx:0  r8: 8b21017f  r9:f
> rax:0 rbx: c0611f40 rbp: fe80018ce060
> r10:0 r11:0 r12: fe81c20ecf00
> r13:   d8c200 r14:2 r15: 826c2240
> fsb: 8000 gsb: 81a6c800  ds:   43
>  es:   43  fs:0  gs:  1c3
> trp:e err:0 rip: f0a6350a
>  cs:   28 rfl:10207 rsp: fe80018ce030
>  ss:   30
> 
> fe80018cde50 unix:real_mode_end+71e1 ()
> fe80018cdf30 unix:trap+5e6 ()
> fe80018cdf40 unix:_cmntrap+140 ()
> fe80018ce060 zfs:zio_buf_alloc+a ()
> fe80018ce090 zfs:arc_buf_alloc+9f ()
> fe80018ce110 zfs:arc_read+ee ()
> fe80018ce190 zfs:dbuf_read_impl+1a0 ()
> fe80018ce1d0 zfs:zfsctl_ops_root+304172dd ()
> fe80018ce200 zfs:dmu_tx_check_ioerr+6e ()
> fe80018ce260 zfs:dmu_tx_count_write+73 ()
> fe80018ce290 zfs:dmu_tx_hold_write+4a ()
> fe80018ce350 zfs:zfs_write+1bb ()
> fe80018ce3a0 genunix:fop_write+31 ()
> fe80018ce410 nfssrv:do_io+b5 ()
> fe80018ce610 nfssrv:rfs4_op_write+40e ()
> fe80018ce770 nfssrv:rfs4_compound+1b3 ()
> fe80018ce800 nfssrv:rfs4_dispatch+234 ()
> fe80018ceb10 nfssrv:common_dispatch+88a ()
> fe80018ceb20 nfssrv:nfs4_drc+3051ccc1 ()
> fe80018cebf0 rpcmod:svc_getreq+209 ()
> fe80018cec40 rpcmod:svc_run+124 ()
> fe80018cec70 rpcmod:svc_do_run+88 ()
> fe80018ceec0 nfs:nfssys+208 ()
> fe80018cef10 unix:brand_sys_sysenter+1f2 ()
> 
> syncing file systems...
>  done
> dumping to /dev/dsk/c0t0d0s1, offset 860356608, content: kernel
> NOTICE: ahci_tran_rese

Re: [zfs-discuss] zpool import hangs

[Erik Gulliksson]

Hi Victor,

Thanks for the prompt reply. Here are the results from your suggestions.

> Panic stack would be useful.
I'm sorry I don't have this available and I don't want to cause another panic :)

>
> It is apparently blocked somewhere in kernel. Try to do something like this
> from another window to get better idea:
>
> echo "::pid2proc|::walk thread|::findtsack -v" | mdb -k
> echo "::threadlist -v" | mdb -k
>
window 1:
bash-3.2# zpool import -f data1
window 2:
bash-3.2# ps -fel | grep zpool
 0 S root   897   874   0  40 20?   1262? 15:03:23
pts/3   0:00 zpool import -f data1
bash-3.2# echo "0t897::pid2proc|::walk thread|::findstack -v" | mdb -k
stack pointer for thread ff01b57ab840: ff00083709f0
[ ff00083709f0 _resume_from_idle+0xf1() ]
  ff0008370a30 swtch+0x17f()
  ff0008370a60 cv_wait+0x61(ff01b3bd71ca, ff01b3bd7188)
  ff0008370ab0 txg_wait_synced+0x81(ff01b3bd7000, 299ee597)
  ff0008370b10 spa_config_update_common+0x79(ff01b42a8a80, 0, 0)
  ff0008370bb0 spa_import_common+0x36e(ff01b5ad4000, ff01b5325310, 0
  , 0, 0)
  ff0008370be0 spa_import+0x1e(ff01b5ad4000, ff01b5325310, 0)
  ff0008370c30 zfs_ioc_pool_import+0xad(ff01b5ad4000)
  ff0008370cb0 zfsdev_ioctl+0x10d(b6, 5a02, 80424f0, 13,
  ff01b3f181a0, ff0008370e9c)
  ff0008370cf0 cdev_ioctl+0x48(b6, 5a02, 80424f0, 13,
  ff01b3f181a0, ff0008370e9c)
  ff0008370d30 spec_ioctl+0x86(ff01adf41d00, 5a02, 80424f0, 13,
  ff01b3f181a0, ff0008370e9c, 0)
  ff0008370db0 fop_ioctl+0x7b(ff01adf41d00, 5a02, 80424f0, 13,
  ff01b3f181a0, ff0008370e9c, 0)
  ff0008370ec0 ioctl+0x174(3, 5a02, 80424f0)
  ff0008370f10 _sys_sysenter_post_swapgs+0x14b()

bash-3.2# echo "::threadlist -v" | mdb -k
Output a bit too long to post here. Is there anything in particular i
should look for in this output?

>
> Some useful information may be logged in FMA, try to see what is available
> there with
>
> fmdump -eV

- I get a few ereport.fs.zfs.checksum reports like this
bash-3.2# fmdump -eV
Aug 22 2008 15:03:23.203687016 ereport.fs.zfs.checksum
nvlist version: 0
class = ereport.fs.zfs.checksum
ena = 0x1a77b8287a1
detector = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = zfs
pool = 0xe2bba51ab8c26b53
vdev = 0x79871af1e1f39de1
(end detector)

pool = data1
pool_guid = 0xe2bba51ab8c26b53
pool_context = 0
pool_failmode = wait
vdev_guid = 0x79871af1e1f39de1
vdev_type = disk
vdev_path = /dev/dsk/c2t2d0s0
vdev_devid = id1,[EMAIL PROTECTED]/a
parent_guid = 0xe2bba51ab8c26b53
parent_type = root
zio_err = 50
zio_offset = 0x1e800416c00
zio_size = 0x400
zio_objset = 0x0
zio_object = 0xb
zio_level = 0
zio_blkid = 0x0
__ttl = 0x1

Aug 22 2008 15:03:23.203687247 ereport.fs.zfs.data
nvlist version: 0
class = ereport.fs.zfs.data
ena = 0x1a77b8287a1
detector = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = zfs
pool = 0xe2bba51ab8c26b53
(end detector)

pool = data1
pool_guid = 0xe2bba51ab8c26b53
pool_context = 0
pool_failmode = wait
zio_err = 50
zio_objset = 0x0
zio_object = 0xb
zio_level = 0
zio_blkid = 0x0
__ttl = 0x1
__tod = 0x48aeb91b 0xc24054f

Aug 22 2008 15:03:23.207225717 ereport.fs.zfs.io_failure
nvlist version: 0
class = ereport.fs.zfs.io_failure
ena = 0x1a77ee27cb1
detector = (embedded nvlist)
nvlist version: 0
version = 0x0
scheme = zfs
pool = 0xe2bba51ab8c26b53
(end detector)

pool = data1
pool_guid = 0xe2bba51ab8c26b53
pool_context = 0
pool_failmode = wait
__ttl = 0x1
__tod = 0x48aeb91b 0xc5a0375

>
> On Nevada you can try the following to  (same option repeated several times
> increases verbosity):
>
> zdb -e -bb data1
> zdb -e - data1
>


bash-3.2# zdb -e -bb data1
Traversing all blocks to verify nothing leaked ...
out of memory -- generating core dump
Abort

Seems i need to get a machine with more ram to do this :) This can be
arranged on monday.


bash-3.2# zdb -e - data1
Dataset mos [META], ID 0, cr_txg 4, 210M, 189 objects, rootbp [L0 DMU
objset] 400L/200P DVA[0]=<0:5680200:200> DVA[1]=<0:320200:200>
DVA[2]=<0:4881800:200> fletcher4 lzjb LE contiguous
birth=698279317 fill=189
cksum=89744d6d8:36e7cf71f81:b1d06b2acd36:1850b4cc5621f3

Object  lvl   iblk   dblk  lsize  asize  type
 0216K16K  96.0K  94.5K  DMU dnode

Object  lvl   iblk   dblk  lsize  asize  type

Re: [zfs-discuss] Possible to do a stripe vdev?

[Bob Friesenhahn]

On Thu, 21 Aug 2008, John wrote:

> I'm setting up a ZFS fileserver using a bunch of spare drives. I'd 
> like some redundancy and to maximize disk usage, so my plan was to 
> use raid-z. The problem is that the drives are considerably 
> mismatched and I haven't found documentation (though I don't see why 
> it shouldn't be possible) to stripe smaller drives together to match 
> bigger ones. The drives are: 1x750, 2x500, 2x400, 2x320, 2x250. Is 
> it possible to accomplish the following with those drives:

The ZFS vdev will only use up to the size of the smallest device in 
it.  If your smallest device is 250GB and another device in the same 
vdev is 350GB, then 100GB of that device will be ignored. While I 
would not really recommend it, a way out of the predicament is to use 
partitioning (via 'format') to partition a large drive into several 
smaller partitions which are similar in size to your smaller drives. 
The reason why this is not recommended is that a single drive failure 
could then take out several logical devices and the vdev and pool 
could be toast.  With care, it could work ok with simple mirrors, but 
mirrors waste 1/2 the physical disk space.

The better solution is to try to build your vdevs out of similar-sized 
disk drives from the start.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], 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] zpool import hangs

[Victor Latushkin]

Erik,

could you please provide a little bit more details.

Erik Gulliksson wrote:
> Hi,
> 
> I have a zfs-pool (unfortunately not setup according to the Best
> Practices Guide) that somehow got corrupted after a spontaneous server
> reboot.

Was it totally spontaneous? What was the uptime before panic? Systems 
messages on you Solaris 10 machine may have some clues.

> On Solaris 10u4 the machine simply panics when I try to import
> the pool. So what I've done is taken a dd-image of the whole LUN so

Is it SAN-based LUN? How many systems can access this LUN? Is there any 
chance that it might get imported by some other system while being in 
use on this one?

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

Re: [zfs-discuss] Possible to do a stripe vdev?

[Nils Goroll]

Hi,

John wrote:
> I'm setting up a ZFS fileserver using a bunch of spare drives. I'd like some 
> redundancy and to maximize disk usage, so my plan was to use raid-z. The 
> problem is that the drives are considerably mismatched and I haven't found 
> documentation (though I don't see why it shouldn't be possible) to stripe 
> smaller drives together to match bigger ones. The drives are: 1x750, 2x500, 
> 2x400, 2x320, 2x250. Is it possible to accomplish the following with those 
> drives:
> 
> raid-z
>750
>500+250=750
>500+250=750
>400+320=720
>400+720=720


Though I've never used this in production, it seems possible to layer ZFS on 
good old SDS (aka SVM, disksuite).

At least I managed to create a trivial pool on 
what-10-mins-ago-was-my-swap-slice:

haggis:/var/tmp# metadb -f -a -c 3 /dev/dsk/c5t0d0s7 
haggis:/var/tmp# metainit d10 1 1 /dev/dsk/c5t0d0s1
d10: Concat/Stripe is setup
haggis:/var/tmp# zpool create test /dev/md/dsk/d10 
haggis:/var/tmp# zpool status test
  pool: test
 state: ONLINE
 scrub: none requested
config:

NAME   STATE READ WRITE CKSUM
test   ONLINE   0 0 0
  /dev/md/dsk/d10  ONLINE   0 0 0

So it looks like you could do the follwing:

* Put a small slice (10-20m should suffice, by convention it's slice 7 on the 
first cylinders) on each of your disks and make them the metadb, if you are not 
using SDS already
  metadb -f -a -c 3 

  make slice 0 the remainder of each disk

* for your 500/250G drives, create a concat (stripe not possible) for each 
pair. for clarity, I'd recommend to include the 750G disk as well (syntax from 
memory, apologies if I'm wrong with details):

metainit d11 1 1 <700G disk>s0
metainit d12 2 1 <500G disk>s0 1 <250G disk>s0
metainit d13 2 1 <500G disk>s0 1 <250G disk>s0
metainit d14 2 1 <400G disk>s0 1 <320G disk>s0
metainit d15 2 1 <400G disk>s0 1 <320G disk>s0

* create a raidz pool on your metadevices

zpool create  raidz /dev/md/dsk/d11 /dev/md/dsk/d12 /dev/md/dsk/d13 
/dev/md/dsk/d14 /dev/md/dsk/d15

Again: I have never tried this, so please don't blame me if this doesn't work.

Nils
 
 
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] zpool import hangs

[Victor Latushkin]

Erik Gulliksson wrote:
> Hi Victor,
> 
> Thanks for the prompt reply. Here are the results from your suggestions.
> 
>> Panic stack would be useful.
> I'm sorry I don't have this available and I don't want to cause another panic 
> :)

It should be saved in system messages on your Solaris 10 machine (unless 
  it's power was not removed  abruptly).

>> It is apparently blocked somewhere in kernel. Try to do something like this
>> from another window to get better idea:
>>
>> echo "::pid2proc|::walk thread|::findtsack -v" | mdb -k
>> echo "::threadlist -v" | mdb -k
>>
> window 1:
> bash-3.2# zpool import -f data1
> window 2:
> bash-3.2# ps -fel | grep zpool
>  0 S root   897   874   0  40 20?   1262? 15:03:23
> pts/3   0:00 zpool import -f data1
> bash-3.2# echo "0t897::pid2proc|::walk thread|::findstack -v" | mdb -k
> stack pointer for thread ff01b57ab840: ff00083709f0
> [ ff00083709f0 _resume_from_idle+0xf1() ]
>   ff0008370a30 swtch+0x17f()
>   ff0008370a60 cv_wait+0x61(ff01b3bd71ca, ff01b3bd7188)
>   ff0008370ab0 txg_wait_synced+0x81(ff01b3bd7000, 299ee597)
>   ff0008370b10 spa_config_update_common+0x79(ff01b42a8a80, 0, 0)
>   ff0008370bb0 spa_import_common+0x36e(ff01b5ad4000, 
> ff01b5325310, 0
>   , 0, 0)
>   ff0008370be0 spa_import+0x1e(ff01b5ad4000, ff01b5325310, 0)
>   ff0008370c30 zfs_ioc_pool_import+0xad(ff01b5ad4000)
>   ff0008370cb0 zfsdev_ioctl+0x10d(b6, 5a02, 80424f0, 13,
>   ff01b3f181a0, ff0008370e9c)
>   ff0008370cf0 cdev_ioctl+0x48(b6, 5a02, 80424f0, 13,
>   ff01b3f181a0, ff0008370e9c)
>   ff0008370d30 spec_ioctl+0x86(ff01adf41d00, 5a02, 80424f0, 13,
>   ff01b3f181a0, ff0008370e9c, 0)
>   ff0008370db0 fop_ioctl+0x7b(ff01adf41d00, 5a02, 80424f0, 13,
>   ff01b3f181a0, ff0008370e9c, 0)
>   ff0008370ec0 ioctl+0x174(3, 5a02, 80424f0)
>   ff0008370f10 _sys_sysenter_post_swapgs+0x14b()
> 
> bash-3.2# echo "::threadlist -v" | mdb -k
> Output a bit too long to post here. Is there anything in particular i
> should look for in this output?

Well, since we are talking about ZFS any thread somewhere in ZFS module 
are interesting, and there should not be too many of them. Though in 
this case it is clear - it is trying to update config object and waits 
for the update to sync. There should be another thread with stack 
similar to this:

genunix:cv_wait()
zfs:zio_wait()
zfs:dbuf_read()
zfs:dmu_buf_will_dirty()
zfs:dmu_write()
zfs:spa_sync_nvlist()
zfs:spa_sync_config_object()
zfs:spa_sync()
zfs:txg_sync_thread()
unix:thread_start()

It wait due to checksum error detected while reading old config object 
from disk (call to dmu_read() above). It means that all ditto-blocks of 
config object got corrupted. On Solaris 10 there's no

>> Some useful information may be logged in FMA, try to see what is available
>> there with
>>
>> fmdump -eV
> 
> - I get a few ereport.fs.zfs.checksum reports like this
> bash-3.2# fmdump -eV
> Aug 22 2008 15:03:23.203687016 ereport.fs.zfs.checksum
> nvlist version: 0
> class = ereport.fs.zfs.checksum
> ena = 0x1a77b8287a1
> detector = (embedded nvlist)
> nvlist version: 0
> version = 0x0
> scheme = zfs
> pool = 0xe2bba51ab8c26b53
> vdev = 0x79871af1e1f39de1
> (end detector)
> 
> pool = data1
> pool_guid = 0xe2bba51ab8c26b53
> pool_context = 0
> pool_failmode = wait
> vdev_guid = 0x79871af1e1f39de1
> vdev_type = disk
> vdev_path = /dev/dsk/c2t2d0s0
> vdev_devid = id1,[EMAIL PROTECTED]/a
> parent_guid = 0xe2bba51ab8c26b53
> parent_type = root
> zio_err = 50
> zio_offset = 0x1e800416c00
> zio_size = 0x400
> zio_objset = 0x0
> zio_object = 0xb
> zio_level = 0
> zio_blkid = 0x0
> __ttl = 0x1
> 
> Aug 22 2008 15:03:23.203687247 ereport.fs.zfs.data
> nvlist version: 0
> class = ereport.fs.zfs.data
> ena = 0x1a77b8287a1
> detector = (embedded nvlist)
> nvlist version: 0
> version = 0x0
> scheme = zfs
> pool = 0xe2bba51ab8c26b53
> (end detector)
> 
> pool = data1
> pool_guid = 0xe2bba51ab8c26b53
> pool_context = 0
> pool_failmode = wait
> zio_err = 50
> zio_objset = 0x0
> zio_object = 0xb
> zio_level = 0
> zio_blkid = 0x0
> __ttl = 0x1
> __tod = 0x48aeb91b 0xc24054f
> 
> Aug 22 2008 15:03:23.207225717 ereport.fs.zfs.io_failure
> nvlist version: 0
> class = ereport.fs.zfs.io_failure
> ena = 0x1a77ee27cb1
> detector = (embedded nvlist)
> nvlist version: 0
> version = 0x0
> scheme = zfs
> 

Re: [zfs-discuss] zpool import hangs

[Erik Gulliksson]

Victor,

> Was it totally spontaneous? What was the uptime before panic? Systems
> messages on you Solaris 10 machine may have some clues.

I actually don't know exactly what happened (this was during my
vacation). Monitoring graphs shows that load was very high on this
particular server this day. Approximately the machine had about 20
days uptime when the panic happened (it is a Sun Fire X4100 btw). I
can't find any log entries from this date unfortunately, will
investigate it further on monday.

> Is it SAN-based LUN? How many systems can access this LUN? Is there any
> chance that it might get imported by some other system while being in use on
> this one?

The LUN (set up as RAID6) is exported from a device that comes from a
vendor called easyRAID, we talk to this device with iSCSI. The
iSCSI-VLANs is tagged in a way that only the crashing server have
access to the box. Do you find anything that indicates that more than
one box imported the pool at the same time?

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

Re: [zfs-discuss] zpool import hangs

[Erik Gulliksson]

Victor,

> Well, since we are talking about ZFS any thread somewhere in ZFS module are
> interesting, and there should not be too many of them. Though in this case
> it is clear - it is trying to update config object and waits for the update
> to sync. There should be another thread with stack similar to this:
>
> genunix:cv_wait()
> zfs:zio_wait()
> zfs:dbuf_read()
> zfs:dmu_buf_will_dirty()
> zfs:dmu_write()
> zfs:spa_sync_nvlist()
> zfs:spa_sync_config_object()
> zfs:spa_sync()
> zfs:txg_sync_thread()
> unix:thread_start()
>

Ok, this would be the thread you're referring to:

ff000746ec80 fbc287b00   0  60 ff01b53ebd88
  PC: _resume_from_idle+0xf1THREAD: txg_sync_thread()
  stack pointer for thread ff000746ec80: ff000746e860
  [ ff000746e860 _resume_from_idle+0xf1() ]
swtch+0x17f()
cv_wait+0x61()
zio_wait+0x5f()
dbuf_read+0x1b5()
dbuf_will_dirty+0x3d()
dmu_write+0xcd()
spa_sync_nvlist+0xa7()
spa_sync_config_object+0x71()
spa_sync+0x20b()
txg_sync_thread+0x226()
thread_start+8()

As you say, there are more zfs/spa/txg-threads that end up in the same
wait-state.

> It wait due to checksum error detected while reading old config object from
> disk (call to dmu_read() above). It means that all ditto-blocks of config
> object got corrupted. On Solaris 10 there's no

Now this is getting interesting. Is there any chance to recover from
this scenario?

>>> Btw, why does timestamp on your uberblock show July 1?
>>
>> Well, this is about the time when the crash happened. The clock on the
>> server is correct.
>
> Wow! Why did you wait almost two months?
There has been a lot on reading up about zfs and finding local
recovery-experts. But yes, of course I should have posted to this
mailing-list earlier.

Again, thanks Victor!

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

Re: [zfs-discuss] Best layout for 15 disks?

[Tim]

14+2 or 7+1



On 8/22/08, Miles Nordin <[EMAIL PROTECTED]> wrote:
>> "m" == mike  <[EMAIL PROTECTED]> writes:
>
>  m> can you combine two zpools together?
>
> no.  You can have many vdevs in one pool.  for example you can have a
> mirror vdev and a raidz2 vdev in the same pool.  You can also destroy
> pool B, and add its (now empty) devices to pool A.  but once two
> separate pools are created you can't later smush them together.
>
> but...since you bring it up, that is exactly what I would do with the
> 16 disks: make two pools.  I'd make one of the pools compressed, make
> backups onto it with zfs send/recv, and leave it exported most of the
> time.  Every week or so I'd spin up the disks, import the pool, write
> another incremental backup onto it, scrub it, export it, and spin the
> disks back down.
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

I hear everyone's concerns about multiple parity disks.

Are there any benchmarks or numbers showing the performance difference using a 
15 disk raidz2 zpool? I am fine sacrificing some performance but obviously 
don't want to make the machine crawl.

It sounds like I could go with 15 disks evenly and have to sacrifice 3, but I 
would have 1 parity disk on each 7 disk raidz1 zpool and a hot spare to cover a 
failure on either pool:

zpool create tank \
raidz disk1 disk2 disk3 disk4 disk5 disk6 disk7 \
raidz disk8 disk9 disk10  disk11 disk12 disk13 disk14 \
spare disk15 

That's pretty much dual parity/dual failure for both pools assuming I swap out 
the dead drive pretty quickly. Yeah?

And terminology-wise, one or more zpools create zdevs right?

Oh, and does raidz2 provide more performance than a raidz1 as it is kind of 
like dual parity and can split up the parity traffic over two devices?

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] Best layout for 15 disks?

[Claus Guttesen]

> Are there any benchmarks or numbers showing the performance difference using 
> a 15 disk raidz2 zpool? I am fine sacrificing some performance but obviously 
> don't want to make the machine crawl.
>
> It sounds like I could go with 15 disks evenly and have to sacrifice 3, but I 
> would have 1 parity disk on each 7 disk raidz1 zpool and a hot spare to cover 
> a failure on either pool:
>
> zpool create tank \
> raidz disk1 disk2 disk3 disk4 disk5 disk6 disk7 \
> raidz disk8 disk9 disk10  disk11 disk12 disk13 disk14 \
> spare disk15

If space is not your first priority I'd go for a zpool with two
raidz2-set each with 8 disk. Then you still have 12 disks at your
disposal.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentlest gamester is the soonest winner.

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

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

Oh sorry - for boot I don't care if it's redundant or anything.

Worst case the drive fails, I replace it and reinstall, and just re-mount the 
ZFS stuff.

If I have the space in the case and the ports I could get a pair of 80 gig 
drives or something and mirror them using SVM (which was recommended to me by 
someone) or use ZFS for it, but I was a bit nervous since ZFS boot is still so 
new, but that'd be just a mirror (raid1 style) nothing fancy there, just good 
enough for booting and liveupgrade

I was told to partition this way to make liveupgrade easy:

/
/lu = identical space as /
swap
 
 
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] Best layout for 15 disks?

[Darren J Moffat]

mike wrote:

> And terminology-wise, one or more zpools create zdevs right?

No that isn't correct.

One or move vdevs create a pool.  Each vdev in a pool can be a different 
type, eg a mix or mirror, raidz, raidz2.

There is no such thing as zdev.

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

Re: [zfs-discuss] Couple of ZFS panics...

[Rustam Aliyev]

Hi Ben,

I'm having exactly same error for a months. In my case problem also 
started soon after update to 10U5. I've SATA mirror pool on ICH6 and 
also share it over NFS.
Do you see checksum errors in zpool stats -xv?

Unfortunately, I haven't found any solution yet.

Regards,
Rustam.



Ben Taylor wrote:
> I've got a Intel DP35DP Motherboard, Q6600 proc (Intel 2.4G, 4 core), 4GB of 
> ram and a
> copule of Sata disks, running ICH9.  S10U5, patched about a week ago or so...
>
> I have a zpool on a single slice (haven't added a mirror yet, was getting to 
> that) and have
> started to suffer regular hard resets and have gotten a few panics.  The 
> system is an 
> nfs server for a couple of systems (not much write) and one writer (I do my 
> svn updates
> over NFS cause my ath0 board refuses to work in 64-bit on S10U5)  I also do 
> local
> builds on the same server.
>
> Ideas?  
>
> The first looks like:
>
> panic[cpu0]/thread=9bcf0460: 
> BAD TRAP: type=e (#pf Page fault) rp=fe80001739a0 addr=c064dba0
>
>
> cmake: 
> #pf Page fault
> Bad kernel fault at addr=0xc064dba0
> pid=6797, pc=0xf0a6350a, sp=0xfe8000173a90, eflags=0x10207
> cr0: 80050033 cr4: 6f8
> cr2: c064dba0 cr3: 12bf9b000 cr8: c
> rdi: 6c60 rsi:0 rdx:0
> rcx:0  r8: 8b21017f  r9: ae3a79c0
> rax:0 rbx: c0611f40 rbp: fe8000173ac0
> r10:0 r11:0 r12: ae4687d0
> r13:   d8c200 r14:2 r15: 826c0480
> fsb: 8000 gsb: fbc24ec0  ds:   43
>  es:   43  fs:0  gs:  1c3
> trp:e err:0 rip: f0a6350a
>  cs:   28 rfl:10207 rsp: fe8000173a90
>  ss:   30
>
> fe80001738b0 unix:real_mode_end+71e1 ()
> fe8000173990 unix:trap+5e6 ()
> fe80001739a0 unix:_cmntrap+140 ()
> fe8000173ac0 zfs:zio_buf_alloc+a ()
> fe8000173af0 zfs:arc_buf_alloc+9f ()
> fe8000173b70 zfs:arc_read+ee ()
> fe8000173bf0 zfs:dbuf_read_impl+1a0 ()
> fe8000173c30 zfs:zfsctl_ops_root+304172dd ()
> fe8000173c60 zfs:dmu_tx_check_ioerr+6e ()
> fe8000173cc0 zfs:dmu_tx_count_write+73 ()
> fe8000173cf0 zfs:dmu_tx_hold_write+4a ()
> fe8000173db0 zfs:zfs_write+1bb ()
> fe8000173e00 genunix:fop_write+31 ()
> fe8000173eb0 genunix:write+287 ()
> fe8000173ec0 genunix:write32+e ()
> fe8000173f10 unix:brand_sys_sysenter+1f2 ()
>
> syncing file systems...
>  3130
>  15
>  done
> dumping to /dev/dsk/c0t0d0s1, offset 860356608, content: kernel
> NOTICE: ahci_tran_reset_dport: port 0 reset port
>
>
> The second liek this:
>
> panic[cpu2]/thread=9b425f20: 
> BAD TRAP: type=e (#pf Page fault) rp=fe80018cdf40 addr=c064dba0
>
>
> nfsd: 
> #pf Page fault
> Bad kernel fault at addr=0xc064dba0
> pid=665, pc=0xf0a6350a, sp=0xfe80018ce030, eflags=0x10207
> cr0: 8005003b cr4: 6f8
> cr2: c064dba0 cr3: 12a9df000 cr8: c
> rdi: 6c60 rsi:0 rdx:0
> rcx:0  r8: 8b21017f  r9:f
> rax:0 rbx: c0611f40 rbp: fe80018ce060
> r10:0 r11:0 r12: fe81c20ecf00
> r13:   d8c200 r14:2 r15: 826c2240
> fsb: 8000 gsb: 81a6c800  ds:   43
>  es:   43  fs:0  gs:  1c3
> trp:e err:0 rip: f0a6350a
>  cs:   28 rfl:10207 rsp: fe80018ce030
>  ss:   30
>
> fe80018cde50 unix:real_mode_end+71e1 ()
> fe80018cdf30 unix:trap+5e6 ()
> fe80018cdf40 unix:_cmntrap+140 ()
> fe80018ce060 zfs:zio_buf_alloc+a ()
> fe80018ce090 zfs:arc_buf_alloc+9f ()
> fe80018ce110 zfs:arc_read+ee ()
> fe80018ce190 zfs:dbuf_read_impl+1a0 ()
> fe80018ce1d0 zfs:zfsctl_ops_root+304172dd ()
> fe80018ce200 zfs:dmu_tx_check_ioerr+6e ()
> fe80018ce260 zfs:dmu_tx_count_write+73 ()
> fe80018ce290 zfs:dmu_tx_hold_write+4a ()
> fe80018ce350 zfs:zfs_write+1bb ()
> fe80018ce3a0 genunix:fop_write+31 ()
> fe80018ce410 nfssrv:do_io+b5 ()
> fe80018ce610 nfssrv:rfs4_op_write+40e ()
> fe80018ce770 nfssrv:rfs4_compound+1b3 ()
> fe80018ce800 nfssrv:rfs4_dispatch+234 ()
> fe80018ceb10 nfssrv:common_dispatch+88a ()
> fe80018ceb20 nfssrv:nfs4_drc+3051ccc1 ()
> fe80018cebf0 rpcmod:svc_getreq+209 ()
> fe80018cec40 rpcmod:svc_run+124 ()
> fe80018cec70 rpcmod:svc_do_run+88 ()
> fe80018ceec0 nfs:nfssys+208 ()
> fe80018cef10 unix:brand_sys_sysenter+1f2 ()
>
> syncing fil

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

> No that isn't correct.

> One or move vdevs create a pool.  Each vdev in a pool can be a
> different type, eg a mix or mirror, raidz, raidz2.

> There is no such thing as zdev.

Sorry :)

Okay, so you can create a zpool from multiple vdevs. But you cannot
add more vdevs to a zpool once the zpool is created. Is that right?
That's what it sounded like someone said earlier.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[Kyle McDonald]

mike wrote:
> And terminology-wise, one or more zpools create zdevs right?
>
Lets get the terminology right first.

You can have more than one zPool.

Each zPool can have many filesystems which all share *ALL* the space in 
the pool.
Each zPool can get it's space from one or more vDevs.

(Yes you can put more than one vDev in a single pool, and space from all 
vDevs is available to all filesystems - No artificial bounadaries here.)

Each vDev can be one of several types.

Single - 1 device  - No redundancy - 100% space usable.
Mirror - 2 devices min - Redundandacy increases as you add mirror devices.
 Available space is equal to smallest device.
RAIDZ1 - 3 devices min - Redundancy allows 1 failure at a time.
 Available space is (n-1) times smallest device.
RAIDZ2 - 4 devices min - Redundancy allows 2 failures at once.
 Available space is (n-2) times smallest device.

You can ( though I don't know why you'd want to) put vDevs of different 
types in the same pool.
>
> zpool create tank \
> raidz disk1 disk2 disk3 disk4 disk5 disk6 disk7 \
> raidz disk8 disk9 disk10  disk11 disk12 disk13 disk14 \
> spare disk15 
>
> That's pretty much dual parity/dual failure for both pools assuming I swap 
> out the dead drive pretty quickly. Yeah?
>
In this example, you have one pool, with 2 vDevs. Each vDev can sustain 
one failure, but 2 failures in either vDev will take out the whole pool.

If you really can afford to trade performance (and no I don't know how 
much you lose) for redundancy, it'd be better to do:

zpool create tank \
 raidz2 disk1  disk2  disk3  disk4  disk5  disk6  disk7 \
disk8  disk9  disk10 disk11 disk12 disk13 disk14 \
 spare  disk15

Since now you can have any 2 disks fail (3 if the spare has time to get 
used,) and the same space as your example.

   -Kyle

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

Re: [zfs-discuss] Best layout for 15 disks?

[Darren J Moffat]

mike wrote:
>> No that isn't correct.
> 
>> One or move vdevs create a pool.  Each vdev in a pool can be a
>> different type, eg a mix or mirror, raidz, raidz2.
> 
>> There is no such thing as zdev.
> 
> Sorry :)
> 
> Okay, so you can create a zpool from multiple vdevs. But you cannot
> add more vdevs to a zpool once the zpool is created. Is that right?

Yes you can add more vdevs.  What you can't do is add more disks to a 
raidz or raidz2 vdev but you can add another raidz vdev to the pool.

For example:

I start out with a pool of 6 disks in a raidz that is one vdev.
I then add another 6 disks raidz that is two vdevs.  Still one pool it
looks like this:

 NAME STATE READ WRITE CKSUM
 cube ONLINE   0 0 0
   raidz1 ONLINE   0 0 0
 c5t0d0   ONLINE   0 0 0
 c5t1d0   ONLINE   0 0 0
 c5t2d0   ONLINE   0 0 0
 c5t3d0   ONLINE   0 0 0
 c5t4d0   ONLINE   0 0 0
 c5t5d0   ONLINE   0 0 0
   raidz1 ONLINE   0 0 0
 c5t8d0   ONLINE   0 0 0
 c5t9d0   ONLINE   0 0 0
 c5t10d0  ONLINE   0 0 0
 c5t11d0  ONLINE   0 0 0
 c5t12d0  ONLINE   0 0 0
 c5t13d0  ONLINE   0 0 0

I could if I wanted to add another vdev to this pool but it doesn't
have to be raidz it could be raidz2 or mirror.

You can add more "sides" to a mirror vdev and you can turn a single
disk vdev into a mirror.

You can not mirror a raidz or raidz a mirror.

> That's what it sounded like someone said earlier.

If they did they are wrong, hope the above clarifies.

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

Re: [zfs-discuss] Best layout for 15 disks?

[Kyle McDonald]

mike wrote:
>
>
> Sorry :)
>
> Okay, so you can create a zpool from multiple vdevs. But you cannot
> add more vdevs to a zpool once the zpool is created. Is that right?
Nope. That's exactly what you *CAN* do.

So say today you only really need 6TB usable, you could go buy 8 of your 
1TB disks,
and setup a pool with a single 7 disk RAIDZ1 vDev, and a single spare 
today. Later
when disks are cheaper, and you need the space you could add a second 7 
disk RAIDZ1
to the pool. This way you'd gradually grow into exaclty the example you 
gave earlier.

Also while it makes sense to use the same size drives in the same vDev, 
additional vDevs you add later can easily be made from different size 
drives. For the exaple above, when you got around to adding the second 
vDev, 2TB disks might be out, for the same space, you could create a 
vDev with fewer 2TB drives, or a vDev with the same number of drives and 
add twice the space, or some combo inbetween - Just because oyur first 
vDev had 7 disks doesn't mean the others have to.

Antoher note, as someone said earlier, if you can go to 16 drives, you 
should consider 2 8disk RAIDZ2 vDevs, over 2 7disk RAIDZ vDevs with a 
spare, or (I would think) even a 14disk RAIDZ2 vDev with a spare.

If you can (now or later) get room to have 17 drives, 2 8disk RAIDZ2 
vDevs with a spare would be your best bet. And remember you can grow 
into it... 1 vDev and spare now, second vDev later.

  -Kyle

> That's what it sounded like someone said earlier.
> ___
> 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] Best layout for 15 disks?

[mike]

On 8/22/08, Darren J Moffat <[EMAIL PROTECTED]> wrote:

> I could if I wanted to add another vdev to this pool but it doesn't
> have to be raidz it could be raidz2 or mirror.

> If they did they are wrong, hope the above clarifies.

I get it now. If you add more disks they have to be in their own
mirror/raidz/etc setup, but they can be added to the same large "pool"
of space.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[Bill Sommerfeld]

On Thu, 2008-08-21 at 21:15 -0700, mike wrote:
> I've seen 5-6 disk zpools are the most recommended setup.

This is incorrect.

Much larger zpools built out of striped redundant vdevs (mirror, raidz1,
raidz2) are recommended and also work well.

raidz1 or raidz2 vdevs of more than a single-digit number of drives are
not recommended.

so, for instance, the following is an appropriate use of 12 drives in
two raidz2 sets of 6 disks, with 8 disks worth of raw space available:

zpool create mypool raidz2 disk0 disk1 disk2 disk3 disk4 disk5
zpool add mypool raidz2 disk6 disk7 disk8 disk9 disk10 disk11

> In traditional RAID terms, I would like to do RAID5 + hot spare (13
> disks usable) out of the 15 disks (like raidz2 I suppose). What would
> make the most sense to setup 15 disks with ~ 13 disks of usable space?

Enable compression, and set up multiple raidz2 groups.  Depending on
what you're storing, you may get back more than you lose to parity.

>  This is for a home fileserver, I do not need HA/hotplugging/etc. so I
> can tolerate a failure and replace it with plenty of time. It's not
> mission critical.

That's a lot of spindles for a home fileserver.   I'd be inclined to go
with a smaller number of larger disks in mirror pairs, allowing me to
buy larger disks in pairs as they come on the market to increase
capacity.

> Same question, but 10 disks, and I'd sacrifice one for parity then.
> Not two. so ~9 disks usable roughly (like raidz)

zpool create mypool raidz1 disk0 disk1 disk2 disk3 disk4
zpool add mypool raidz1 disk5 disk6 disk7 disk8 disk9

8 disks raw capacity, can survive the loss of any one disk or the loss
of two disks in different raidz groups.


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

Re: [zfs-discuss] Best layout for 15 disks?

[Rich Teer]

On Fri, 22 Aug 2008, mike wrote:

> Oh sorry - for boot I don't care if it's redundant or anything.

8-O

> Worst case the drive fails, I replace it and reinstall, and just re-mount the 
> ZFS stuff.

If you use a ZFS mirrored root, you just replace a drive when it
fails.  None of this reinstall nonsense.

> If I have the space in the case and the ports I could get a pair of
> 80 gig drives or something and mirror them using SVM (which was
> recommended to me by someone) or use ZFS for it, but I was a bit
> nervous since ZFS boot is still so new, but that'd be just a mirror

ZFS boot works fine; it only recently integrated into Nevada, but it
has been in use for quite some time now.

> I was told to partition this way to make liveupgrade easy:
> 
> /
> /lu = identical space as /
> swap

Even better: just use ZFS root and let it handle the details.

-- 
Rich Teer, SCSA, SCNA, SCSECA

CEO,
My Online Home Inventory

URLs: http://www.rite-group.com/rich
  http://www.linkedin.com/in/richteer
  http://www.myonlinehomeinventory.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

On 8/22/08, Kyle McDonald <[EMAIL PROTECTED]> wrote:

> Antoher note, as someone said earlier, if you can go to 16 drives, you
> should consider 2 8disk RAIDZ2 vDevs, over 2 7disk RAIDZ vDevs with a spare,
> or (I would think) even a 14disk RAIDZ2 vDev with a spare.
>
> If you can (now or later) get room to have 17 drives, 2 8disk RAIDZ2 vDevs
> with a spare would be your best bet. And remember you can grow into it... 1
> vDev and spare now, second vDev later.

This is actually probably a good idea for me, as buying that many
disks right now would be a huge dent in the budget. Although it's for
a good cause, I have a network of slowly overheating drives in USB
cases with data spread all over the place. Bitrot is a daily concern.

I guess I can go with an 8 disk raidz2 to start with; and add a second
one later. That's a decent % of the overall cost of the machine going
towards parity...
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

It looks like this will be the way I do it:

initially:
zpool create mypool raidz2 disk0 disk1 disk2 disk3 disk4 disk5 disk6 disk7

when I need more space and buy 8 more disks:
zpool add mypool raidz2 disk8 disk9 disk10 disk11 disk12 disk13 disk14 disk15

Correct?


> Enable compression, and set up multiple raidz2 groups.  Depending on
> what you're storing, you may get back more than you lose to parity.

It's DVD backups and media files. Probably everything has already been
compressed pretty well by the time it hits ZFS.

> That's a lot of spindles for a home fileserver.   I'd be inclined to go
> with a smaller number of larger disks in mirror pairs, allowing me to
> buy larger disks in pairs as they come on the market to increase
> capacity.

Or do smaller groupings of raidz1's (like 3 disks) so I can remove
them and put 1.5TB disks in when they come out for instance?
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

On 8/22/08, Rich Teer <[EMAIL PROTECTED]> wrote:

> ZFS boot works fine; it only recently integrated into Nevada, but it
> has been in use for quite some time now.

Yeah I got the install option when I installed snv_94 but wound up not
having enough disks to use it.

> Even better: just use ZFS root and let it handle the details.

I assume since it's ZFS root it can make it's own filesystem then for
liveupgrade or something (that's the "details" you speak of) - in that
case, I'm cool with that.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Possible to do a stripe vdev?

[Chris Cosby]

About the best I can see:

zpool create dirtypool raidz 250a 250b 320a raidz 320b 400a 400b raidz 500a
500b 750a

And you have to do them in that order. The zpool will create using the
smallest device. This gets you about 2140GB (500 + 640 + 1000) of space.
Your desired method is only 2880GB (720 * 4) and is WAY harder to setup and
maintain, especially if you get into the SDS configuration.

I, for one, welcome our convoluted configuration overlords. I'd also like to
see what the zpool looks like if it works. This is, obviously, untested.

chris


On Fri, Aug 22, 2008 at 11:03 AM, Nils Goroll <[EMAIL PROTECTED]>wrote:

> Hi,
>
> John wrote:
> > I'm setting up a ZFS fileserver using a bunch of spare drives. I'd like
> some redundancy and to maximize disk usage, so my plan was to use raid-z.
> The problem is that the drives are considerably mismatched and I haven't
> found documentation (though I don't see why it shouldn't be possible) to
> stripe smaller drives together to match bigger ones. The drives are: 1x750,
> 2x500, 2x400, 2x320, 2x250. Is it possible to accomplish the following with
> those drives:
> >
> > raid-z
> >750
> >500+250=750
> >500+250=750
> >400+320=720
> >400+720=720
>
>
> Though I've never used this in production, it seems possible to layer ZFS
> on good old SDS (aka SVM, disksuite).
>
> At least I managed to create a trivial pool on
> what-10-mins-ago-was-my-swap-slice:
>
> haggis:/var/tmp# metadb -f -a -c 3 /dev/dsk/c5t0d0s7
> haggis:/var/tmp# metainit d10 1 1 /dev/dsk/c5t0d0s1
> d10: Concat/Stripe is setup
> haggis:/var/tmp# zpool create test /dev/md/dsk/d10
> haggis:/var/tmp# zpool status test
>  pool: test
>  state: ONLINE
>  scrub: none requested
> config:
>
>NAME   STATE READ WRITE CKSUM
>test   ONLINE   0 0 0
>  /dev/md/dsk/d10  ONLINE   0 0 0
>
> So it looks like you could do the follwing:
>
> * Put a small slice (10-20m should suffice, by convention it's slice 7 on
> the first cylinders) on each of your disks and make them the metadb, if you
> are not using SDS already
>  metadb -f -a -c 3 
>
>  make slice 0 the remainder of each disk
>
> * for your 500/250G drives, create a concat (stripe not possible) for each
> pair. for clarity, I'd recommend to include the 750G disk as well (syntax
> from memory, apologies if I'm wrong with details):
>
> metainit d11 1 1 <700G disk>s0
> metainit d12 2 1 <500G disk>s0 1 <250G disk>s0
> metainit d13 2 1 <500G disk>s0 1 <250G disk>s0
> metainit d14 2 1 <400G disk>s0 1 <320G disk>s0
> metainit d15 2 1 <400G disk>s0 1 <320G disk>s0
>
> * create a raidz pool on your metadevices
>
> zpool create  raidz /dev/md/dsk/d11 /dev/md/dsk/d12 /dev/md/dsk/d13
> /dev/md/dsk/d14 /dev/md/dsk/d15
>
> Again: I have never tried this, so please don't blame me if this doesn't
> work.
>
> Nils
>
>
> This message posted from opensolaris.org
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>



-- 
chris -at- microcozm -dot- net
=== Si Hoc Legere Scis Nimium Eruditionis Habes
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[Chris Cosby]

On Fri, Aug 22, 2008 at 1:08 PM, mike <[EMAIL PROTECTED]> wrote:

> It looks like this will be the way I do it:
>
> initially:
> zpool create mypool raidz2 disk0 disk1 disk2 disk3 disk4 disk5 disk6 disk7
>
> when I need more space and buy 8 more disks:
> zpool add mypool raidz2 disk8 disk9 disk10 disk11 disk12 disk13 disk14
> disk15
>
> Correct?
>
>
> > Enable compression, and set up multiple raidz2 groups.  Depending on
> > what you're storing, you may get back more than you lose to parity.
>
> It's DVD backups and media files. Probably everything has already been
> compressed pretty well by the time it hits ZFS.
>
> > That's a lot of spindles for a home fileserver.   I'd be inclined to go
> > with a smaller number of larger disks in mirror pairs, allowing me to
> > buy larger disks in pairs as they come on the market to increase
> > capacity.
>
> Or do smaller groupings of raidz1's (like 3 disks) so I can remove
> them and put 1.5TB disks in when they come out for instance?

Somebody correct me if I'm wrong. ZFS (early versions) did not support
removing zdevs from a pool. It was a future feature. Is it done yet?


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



-- 
chris -at- microcozm -dot- net
=== Si Hoc Legere Scis Nimium Eruditionis Habes
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[Kyle McDonald]

mike wrote:
> Or do smaller groupings of raidz1's (like 3 disks) so I can remove
> them and put 1.5TB disks in when they come out for instance?
>   

I wouldn't reduce it to 3 disks (should almost mirror if you go that low.)

Remember, while you can't take a drive out of a vDev, or a vDev out of a 
pool, you can *replace* the drives in a vDev.

For example if you have 8 1TB drives in a RAIDZ (1 or 2) vDev, and buy 8 
1.5TB drives, instead of adding a second vDev which is always an option, 
you can replace 1 drive at a time, and as soon as the last drive in the 
vDev is swapped, you'll see the space in the pool jump.

Granted, if you need to buy drives gradually, swapping out 3 at at time 
(with 3 drive vDevs) is easier than 8 at a time, but you'll lose 33% of 
your space to parity, instead of 25% and you'll only be able to lose one 
disk (of each set of 3) at a time.

  -Kyle

> ___
> 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] Best layout for 15 disks?

[Jacob Ritorto]

While on the subject, in a home scenario where one actually notices
the electric bill personally, is it more economical to purchase a big
expensive 1tb disk and save on electric to run it for five years or to
purchase two cheap 1/2 TB disk and spend double on electric for them
for 5 years?  Has anyone calculated this?

If this is too big a turn for this thread, let's start a new one
and/or perhaps find an appropriate forum.

thx
jake

On Fri, Aug 22, 2008 at 1:14 PM, Chris Cosby <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Aug 22, 2008 at 1:08 PM, mike <[EMAIL PROTECTED]> wrote:
>>
>> It looks like this will be the way I do it:
>>
>> initially:
>> zpool create mypool raidz2 disk0 disk1 disk2 disk3 disk4 disk5 disk6 disk7
>>
>> when I need more space and buy 8 more disks:
>> zpool add mypool raidz2 disk8 disk9 disk10 disk11 disk12 disk13 disk14
>> disk15
>>
>> Correct?
>>
>>
>> > Enable compression, and set up multiple raidz2 groups.  Depending on
>> > what you're storing, you may get back more than you lose to parity.
>>
>> It's DVD backups and media files. Probably everything has already been
>> compressed pretty well by the time it hits ZFS.
>>
>> > That's a lot of spindles for a home fileserver.   I'd be inclined to go
>> > with a smaller number of larger disks in mirror pairs, allowing me to
>> > buy larger disks in pairs as they come on the market to increase
>> > capacity.
>>
>> Or do smaller groupings of raidz1's (like 3 disks) so I can remove
>> them and put 1.5TB disks in when they come out for instance?
>
> Somebody correct me if I'm wrong. ZFS (early versions) did not support
> removing zdevs from a pool. It was a future feature. Is it done yet?
>
>>
>> ___
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
>
>
> --
> chris -at- microcozm -dot- net
> === Si Hoc Legere Scis Nimium Eruditionis Habes
>
> ___
> 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] Best layout for 15 disks?

[Kyle McDonald]

mike wrote:
> On 8/22/08, Rich Teer <[EMAIL PROTECTED]> wrote:
>
>   
>> ZFS boot works fine; it only recently integrated into Nevada, but it
>> has been in use for quite some time now.
>> 
>
> Yeah I got the install option when I installed snv_94 but wound up not
> having enough disks to use it.
>
>   
You only need 1 disk to use ZFS root. You won't have any redundancy, but 
as Darren said in another email, you can convert single device vDevs to 
Mirror'd vDevs later without any hassle.
>> Even better: just use ZFS root and let it handle the details.
>> 
>
> I assume since it's ZFS root it can make it's own filesystem then for
> liveupgrade or something (that's the "details" you speak of) - in that
> case, I'm cool with that.
>   
Exactly. Filesystems can be created on the fly at any time on ZFS. I 
think it's actually Live Upgrade (today) or SnapUpgrade (the future) 
that will manage creating the ZFS's for you.

  -Kyle

> ___
> 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] Best layout for 15 disks?

[mike]

On 8/22/08, Kyle McDonald <[EMAIL PROTECTED]> wrote:

> You only need 1 disk to use ZFS root. You won't have any redundancy, but as
> Darren said in another email, you can convert single device vDevs to
> Mirror'd vDevs later without any hassle.

I'd just get some 80 gig disks and mirror them. Might as well :) (as
long as I'm not killing my power supply limits with it)

> Exactly. Filesystems can be created on the fly at any time on ZFS. I think
> it's actually Live Upgrade (today) or SnapUpgrade (the future) that will
> manage creating the ZFS's for you.

Awesome. Excellent reuse of the technology available.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Possible to do a stripe vdev?

[Kyle McDonald]

Chris Cosby wrote:
> About the best I can see:
>
> zpool create dirtypool raidz 250a 250b 320a raidz 320b 400a 400b raidz 
> 500a 500b 750a
>
> And you have to do them in that order. The zpool will create using the 
> smallest device. This gets you about 2140GB (500 + 640 + 1000) of 
> space. Your desired method is only 2880GB (720 * 4) and is WAY harder 
> to setup and maintain, especially if you get into the SDS configuration.
>
> I, for one, welcome our convoluted configuration overlords. I'd also 
> like to see what the zpool looks like if it works. This is, obviously, 
> untested.
>
I don't think I'd be that comfortable doing it, but I suppose you could 
just add each drive as a separate vDev, and set copies=2, but even that 
would get you about 1825GB (If my math is right the disks add up to 3650GB)

  -Kyle

> chris
>
>
> On Fri, Aug 22, 2008 at 11:03 AM, Nils Goroll <[EMAIL PROTECTED] 
> > wrote:
>
> Hi,
>
> John wrote:
> > I'm setting up a ZFS fileserver using a bunch of spare drives.
> I'd like some redundancy and to maximize disk usage, so my plan
> was to use raid-z. The problem is that the drives are considerably
> mismatched and I haven't found documentation (though I don't see
> why it shouldn't be possible) to stripe smaller drives together to
> match bigger ones. The drives are: 1x750, 2x500, 2x400, 2x320,
> 2x250. Is it possible to accomplish the following with those drives:
> >
> > raid-z
> >750
> >500+250=750
> >500+250=750
> >400+320=720
> >400+720=720
>
>
> Though I've never used this in production, it seems possible to
> layer ZFS on good old SDS (aka SVM, disksuite).
>
> At least I managed to create a trivial pool on
> what-10-mins-ago-was-my-swap-slice:
>
> haggis:/var/tmp# metadb -f -a -c 3 /dev/dsk/c5t0d0s7
> haggis:/var/tmp# metainit d10 1 1 /dev/dsk/c5t0d0s1
> d10: Concat/Stripe is setup
> haggis:/var/tmp# zpool create test /dev/md/dsk/d10
> haggis:/var/tmp# zpool status test
>  pool: test
>  state: ONLINE
>  scrub: none requested
> config:
>
>NAME   STATE READ WRITE CKSUM
>test   ONLINE   0 0 0
>  /dev/md/dsk/d10  ONLINE   0 0 0
>
> So it looks like you could do the follwing:
>
> * Put a small slice (10-20m should suffice, by convention it's
> slice 7 on the first cylinders) on each of your disks and make
> them the metadb, if you are not using SDS already
>  metadb -f -a -c 3 
>
>  make slice 0 the remainder of each disk
>
> * for your 500/250G drives, create a concat (stripe not possible)
> for each pair. for clarity, I'd recommend to include the 750G disk
> as well (syntax from memory, apologies if I'm wrong with details):
>
> metainit d11 1 1 <700G disk>s0
> metainit d12 2 1 <500G disk>s0 1 <250G disk>s0
> metainit d13 2 1 <500G disk>s0 1 <250G disk>s0
> metainit d14 2 1 <400G disk>s0 1 <320G disk>s0
> metainit d15 2 1 <400G disk>s0 1 <320G disk>s0
>
> * create a raidz pool on your metadevices
>
> zpool create  raidz /dev/md/dsk/d11 /dev/md/dsk/d12
> /dev/md/dsk/d13 /dev/md/dsk/d14 /dev/md/dsk/d15
>
> Again: I have never tried this, so please don't blame me if this
> doesn't work.
>
> Nils
>
>
> This message posted from opensolaris.org 
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org 
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
>
>
>
> -- 
> chris -at- microcozm -dot- net
> === Si Hoc Legere Scis Nimium Eruditionis Habes
> 
>
> ___
> 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] boot device != zfs root pool device : Is it possible?

[Gordon Ross]

I'd like to experiment with storing the boot archive
on a compact flash that emulates an IDE hard disk,
but then have the root pool on a 4-disk raidz set.
(I'm using OpenSolaris)

Anyone have suggestions on how to go about this?
Will I need to set rootdev in /etc/system to tell the
kernel the root device is different from the boot dev?

Then what about "update-archive" and friends?
They'll need to know where to put the archive,
or get the boot device mounted on /boot or
whatever.

Ideas?  Pointers?

Thanks,
Gordon
 
 
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] Best layout for 15 disks?

[Bob Friesenhahn]

On Fri, 22 Aug 2008, Jacob Ritorto wrote:

> While on the subject, in a home scenario where one actually notices
> the electric bill personally, is it more economical to purchase a big
> expensive 1tb disk and save on electric to run it for five years or to
> purchase two cheap 1/2 TB disk and spend double on electric for them
> for 5 years?  Has anyone calculated this?

In terms of potential data loss, more smaller disks will be more 
reliable and there is less risk of a problem while replacing a failed 
disk.  In terms of cost, the 1/2 size disk may be of the same 
quality/performance grade but cost 1/2 as much as the bleeding-edge 
capacity disk.  Power consumption has more to do with the drive's 
targeted application than its raw capacity.  Solaris supports 
power-management so you could allow it to spin down the drives when 
they are not being used, with the limitation that it might take 30 
seconds before data is available if you have been away for a while. 
If the drives are spun down, zfs's access behavior will cause all of 
them to spin up at once.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], 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] Best layout for 15 disks?

[Miles Nordin]

> "m" == mike  <[EMAIL PROTECTED]> writes:

 m> that could only be accomplished through combinations of pools?
 m> i don't really want to have to even think about managing two
 m> separate "partitions" - i'd like to group everything together
 m> into one large 13tb instance

You're not misreading the web pages.  You can do that.  I suggested
two pools because of problems like Erik's, and other known bugs.  two
pools will also protect you from operator mistakes, like if you
cut-and-paste the argument to 'zfs destroy' and end up with an
embedded newline in the cut buffer at exactly the wrong spot, or
mistakenly add an unredundant vdev, or get confused about how the
snapshot tree works, or upgrade your on-disk-format then want to
downgrade Solaris, or whatever.  This mailing list is a catalog of
reasons you need to have an offline backup pool, and you have enough
disks to do it.  The datacenter crowd on the list doesn't need this
because they have tape, or they have derived datasets which can be
recreated.  You do need it.

I think you've gotten to the ``try it and see'' stage.  Why not try
making pools in a bunch of different combinations and loading them
with throwaway data.  You can test performance.  try scrubbing.  test
the redundancy by pulling drives, and see how the hot sparing works.
Try rebooting during a hot-spare resilver, because during the actual
rebuild this will probably happen a few times until you track down the
driver's poor error handling of a marginal drive.  deliberately
include marginal drives in the pool if you have some.  You can get
really better information this way, especially if the emails are too
long to read.

if you want a list of things to test :)

seriously though if you have sixteen empty drives, that's a fantastic
situation.  I never had that---I had to move my sixteen drives into
zfs, 2 - 4 drives at a time.  I think you ought to use your array for
testing for at least a month.  You need to burn in the drives for a
month anyway because of infant mortality.

 m> you cannot add more vdevs to a zpool once the zpool is
 m> created. Is that right?  That's what it sounded like someone
 m> said earlier.

I didn't mean to say that.  If you have empty devices, of course you
can add them to a pool as a new vdev (though, as Darern said, once a
vdev is added, you're stuck with a vdev of that type, and if it's
raidz{,2} of that stripe-width, for the life of the pool.  you can
never remove a vdev.).  you asked:

 m> can you combine two zpools together?

you can't combine two existing pools and keep the data in tact.  You
have to destroy one pool and add its devices to the other.  I'm
repeating myself:

 m> can you combine two zpools together?

 c> no.  You can have many vdevs in one pool.  for example you can
 c> have a mirror vdev and a raidz2 vdev in the same pool.  You
 c> can also destroy pool B, and add its (now empty) devices to
 c> pool A.  but once two separate pools are created you can't
 c> later smush them together.

so, I am not sure how this sounds.  I usually rely on you to read the
whole paragraph not the first word, but I guess the messages are just
too long.  How about ``yes, you can combine two pools.  But before
combining them you have to destroy one of the pools and all the data
inside it.  then, you can add the empty space to the other pool.''


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

[zfs-discuss] zpool autoexpand property - HowTo question

[Gordon Ross]

I noted this PSARC thread with interest:
  Re: zpool autoexpand property [PSARC/2008/353 Self Review]
because it so happens that during a recent disk upgrade,
on a laptop. I've migrated a zpool off of one partition
onto a slightly larger one, and I'd like to somehow tell
zfs to grow the zpool to fill the new partition.  So,
what's the best way to do this?  (and is it safe?:)

Thanks,
Gordon
 
 
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] Best layout for 15 disks?

[Ross]

Yes, that looks pretty good mike.  There are a few limitations to that as you 
add the 2nd raidz2 set, but nothing major.  When you add the extra disks, your 
original data will still be stored on the first set of disks, if you've any 
free space left on those you'll then get some data stored across all the disks, 
and then I think that once the first set are full, zfs will just start using 
the free space on the newer 8.

It shouldn't be a problem for a home system, and all that will happen silently 
in the background.  It's just worth knowing that you don't necessarily get the 
full performance of a 16 disk array when you do it in two stages like that.

Also, you mentioned in an earlier post about dual parity raid.  Raid-z2 is very 
different from raid-z1, and it's not just a case of having a hot spare.  Having 
the ability to loose two drives before data loss makes a massive difference to 
your chance of experiencing data loss.  The most dangerous period on a raidz 
(or raid-5) pool is after a drive fails, when you're rebuilding the data onto a 
new disk, and with larger drives the risk is increasing.

While you're rebuilding the array, your data isn't protected at all, but you're 
having to re-read all of it in order to populate the new disk.  Any errors 
during that read will result in data corruption at best, and a dead raid array 
at worst.  With drives getting bigger, the chances of an error are increasing.  
From memory I think it's something around a 10% chance of an error for every 
5TB you're rebuilding.

Of course, that could well be just a single bit error, but I've seen a fair few 
raid-5 arrays die and experienced a couple of near misses, so I'm very paranoid 
now when it comes to my data.

Ross
 
 
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] Best layout for 15 disks?

[mike]

On 8/22/08, Ross <[EMAIL PROTECTED]> wrote:

> Yes, that looks pretty good mike.  There are a few limitations to that as you 
> add the 2nd raidz2 set, but nothing major.  When you add the extra disks, 
> your original data will still be stored on the first set of disks, if you've 
> any free space left on those you'll then get some data stored across all the 
> disks, and then I think that once the first set are full, zfs will just start 
> using the free space on the newer 8.

> It shouldn't be a problem for a home system, and all that will happen 
> silently in the background.  It's just worth knowing that you don't 
> necessarily get the full performance of a 16 disk array when you do it in two 
> stages like that.

that's fine. I'll basically be getting the performance of an 8 disk
raidz2 at worst, yeah? i'm fine with how the space will be
distributed. after all this is still a huge improvement over my
current haphazard setup :P
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[Ross Smith]

Yup, you got it, and an 8 disk raid-z2 array should still fly for a home system 
:D  I'm guessing you're on gigabit there?  I don't see you having any problems 
hitting the bandwidth limit on it.

Ross


> Date: Fri, 22 Aug 2008 11:11:21 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [zfs-discuss] Best layout for 15 disks?
> CC: zfs-discuss@opensolaris.org
> 
> On 8/22/08, Ross <[EMAIL PROTECTED]> wrote:
> 
> > Yes, that looks pretty good mike.  There are a few limitations to that as 
> > you add the 2nd raidz2 set, but nothing major.  When you add the extra 
> > disks, your original data will still be stored on the first set of disks, 
> > if you've any free space left on those you'll then get some data stored 
> > across all the disks, and then I think that once the first set are full, 
> > zfs will just start using the free space on the newer 8.
> 
> > It shouldn't be a problem for a home system, and all that will happen 
> > silently in the background.  It's just worth knowing that you don't 
> > necessarily get the full performance of a 16 disk array when you do it in 
> > two stages like that.
> 
> that's fine. I'll basically be getting the performance of an 8 disk
> raidz2 at worst, yeah? i'm fine with how the space will be
> distributed. after all this is still a huge improvement over my
> current haphazard setup :P

_
Get Hotmail on your mobile from Vodafone 
http://clk.atdmt.com/UKM/go/107571435/direct/01/___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Best layout for 15 disks?

[mike]

yeah i am on gigabit, but the clients are things like an xbox which is
only 10/100, etc. right now the setup works fine. i'm thinking the new
CIFS implementation should make it run even cleaner too.

On 8/22/08, Ross Smith <[EMAIL PROTECTED]> wrote:
> Yup, you got it, and an 8 disk raid-z2 array should still fly for a home
> system :D  I'm guessing you're on gigabit there?  I don't see you having any
> problems hitting the bandwidth limit on it.
>
> Ross
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] zpool autoexpand property - HowTo question

[A Darren Dunham]

On Fri, Aug 22, 2008 at 10:54:00AM -0700, Gordon Ross wrote:
> I noted this PSARC thread with interest:
>   Re: zpool autoexpand property [PSARC/2008/353 Self Review]
> because it so happens that during a recent disk upgrade,
> on a laptop. I've migrated a zpool off of one partition
> onto a slightly larger one, and I'd like to somehow tell
> zfs to grow the zpool to fill the new partition.

Depending on exactly how you did it, that should have already happened.
A pool will expand automatically (even in situations where you might not
want it to.)

Can you show details of your existing configuration that show that it
hasn't expanded?

I believe (but am not certain) that the PSARC you refer to only has to
do with expanding LUNs.  Since you mentioned a "migration", I assume you
didn't expand the existing storage.  Is that correct?

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

[zfs-discuss] Upgrading my ZFS server

[Joe S]

I'm want to upgrade the hardware of my Open Solaris b95 server at
home. It's currently running on 32 bit intel hardware. I'm going 64
bit with the new hardware. I don't need server grade hardware since
this is a home server. This means I'm not buying the an Opteron or
Xeon, or any quad core processor. These were too expensive for my
budget. Desktop grade hardware will be fine. I want something that is
energy efficient, not expensive, and with room for expansion. I want
multiple PCIe (pci express) slots so that I can add an LSI MPT based
SATA HBA (requires x4 or x8) and an Intel dual gigabit nic (requires
x4) in the future. I've got my hardware selection down to a few
choices and was hoping someone could comment on their experiences with
any of this hardware. I've determined that in my situation, the
biggest determining factor is how well the chipset is supported in
Open Solaris.

If I choose to go Intel, I like the Intel X38 chipset because it is
the only current Intel chipset that supports ECC memory. This list
contains a number of threads encouraging the use of ECC memory, so I'd
like to use ECC memory. All of the chipsets I list here support ECC
memory. Also, I've read that Open Solaris has better support for CPU
frequency scaling on Intel processors than AMD ( < family 16 )
processors. Anyways, here is the Intel configuration I came up with:

CPU - Intel Core 2 Duo E8400 Wolfdale 3.0GHz LGA 775 65W Dual-Core ($169.99)
Motherboard - Intel DX38BT ($209.99)
 * Intel X38chipset
 * 6x SATA, 2x eSATA
 * 2x PCIe 2.0 x16 slots
 * 1x PCIe 1.0a x16 (electrical x4)
 * 1x Intel 82566DC gigabit ethernet

>From what I read, the X38 is not very different from the 925 chipset
which is supported well in Open Solaris. Also, I chose the Intel
chipset over the nVidia nForice chipsets because I guessed that Intel
CPU + Intel chipset would be a safe bet.

For the AMD configuration, I had trouble picking a chipset. nForce or
AMD? I don't know. Picking the CPU was easy. Here is the AMD + nForce
configuration:

CPU - AMD Athlon X2 4850e 2.5GHz 2 x 512KB L2 Cache Socket AM2 45W
Dual-Core ($77.00)
Motherboard - XFX MDA72P7509 ($134.99)
 * nVidia nForce 750a SLI chipset
 * 6x SATA, 1x eSATA
 * 2x PCIe 2.0 x16
 * nVidia GeForce 8 series integrated video
 * 1x Marvell gigabit ethernet

Here is the AMD + AMD 790GX configuration:

CPU - AMD Athlon X2 4850e 2.5GHz 2 x 512KB L2 Cache Socket AM2 45W
Dual-Core ($77.00)
Motherboard - ASUS M3A78-T ($149.99)
 * AMD 790GX / SB750 chipset
 * 5x, 1x eSATA (no optimal, since I need 6, but if this is the better
chipset, i'll get my sata hba sooner)
 * 3 x PCIe 2.0 x16
 * ATI Radeon HD 3300 GPU
 * 1x Marvell 88E8056 gigabit ethernet

I picked the 790GX of the 790 series because it has integrated video.
Also, I avoided the SB600 southbridge as I have read there are SATA
DMA issues with it. The nForce and AMD chipsets are very new but
aren't too different from their predecessors. I don't mind going AMD
because the CPU is rated at 45W, so I won't completely miss the
benefits of the CPU frequency scaling that the Intel supports. Right
now, I'm leaning towards the AMD + nForce 750a configuration. But the
Intel option isn't bad either. Sun sells the Intel X38 in the Ultra 24
workstation. The AMD 790 option is there because I'm not sure which
chipset to choose from for AMD processors.

So, have any of you used any of these chipsets with Open Solaris? Any
success or failure stories?
Are there any reasons I should steer far away from any of the above chipsets?
Any solid reason I should pick one CPU over the other?

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

Re: [zfs-discuss] ZFS deduplication

[Jim Klimov]

Just my 2c: Is it possible to do an "offline" dedup, kind of like snapshotting?

What I mean in practice, is: we make many Solaris full-root zones. They share a 
lot of data as complete files. This is kind of easy to save space - make one 
zone as a template, snapshot/clone its dataset, make new zones.

However, as projects evolve (software installed, etc.) these zones are filled 
with many similar files, many of which are duplicates.

It seems reasonable to make some dedup process which would create a 
least-common-denominator snapshot for all the datasets involved (zone roots), 
of which all other datasets' current data are to be dubbed "clones with 
modified data". 

For the system (and user) it should be perceived just the same as these 
datasets are currently "clones with modified data" of the original template 
zone-root dataset. Only the "template" becomes different...

Hope this idea makes sense, and perhaps makes its way into code sometime :)
 
 
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] Upgrading my ZFS server

[Brandon High]

On Fri, Aug 22, 2008 at 1:30 PM, Joe S <[EMAIL PROTECTED]> wrote:
> I picked the 790GX of the 790 series because it has integrated video.

The 790GX is a high-clocked 780G, so look at that chipset as well. The
boards are slightly cheaper, too. If you're not overclocking or
running Crossfire, there's no reason to use the GX.

> Also, I avoided the SB600 southbridge as I have read there are SATA
> DMA issues with it. The nForce and AMD chipsets are very new but

The SB700 has a few issues with AHCI as well from what I've heard,
though the specifics are eluding me at the moment. The SB750 is too
new to know but may be an improvement. I'd recommend an LSI 1068e
based HBA like the Supermicro AOC-USAS-L8i.

You may want to put an Intel NIC into the AMD system, since support
with other ethernet solutions seems spotty at best.

-B

-- 
Brandon High [EMAIL PROTECTED]
"You can't blow things up with schools and hospitals." -Stephen Dailey
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss