Re: [zfs-discuss] Good tower server for around 1,250 USD?

This is a very nice chasis IMHO for a desktop machine: http://www.supermicro.com/products/chassis/4U/743/SC743TQ-865-SQ.cfm I use it for my workstation at work. Supermicro makes very high quality chasis. I got this for under $300 USD when I bought mine. You can also get rails and take off its

Re: [zfs-discuss] 350TB+ storage solution

On 05/15/2011 09:58 PM, Richard Elling wrote: In one of my systems, I have 1TB mirrors, 70% full, which can be sequentially completely read/written in 2 hrs. But the resilver took 12 hours of idle time. Supposing you had a 70% full pool of raidz3, 2TB disks, using 10 disks + 3 parity, and a u

Re: [zfs-discuss] RAID Failure Calculator (for 8x 2TB RAIDZ)

I think as far as data integrity and complete volume loss is most likely in the following order: 1. 1x Raidz(7+1) 2. 2x RaidZ(3+1) 3. 1x Raidz2(6+2) Simple raidz certainly is an option with only 8 disks (8 is about the maximum I would go) but to be honest I would feel safer going raidz2. The

Re: [zfs-discuss] 3TB HDD in ZFS

On 12/06/2010 05:17 AM, taemun wrote: > On 6 December 2010 21:43, Fred Liu > wrote: > > 3TB HDD needs UEFI not the traditional BIOS and OS support. > > > > Fred > > > Fred: > http://www.anandtech.com/show/3858/the-worlds-first-3tb-hdd-seagate-goflex-desk-

Re: [zfs-discuss] Erratic behavior on 24T zpool

Sounds to me like something is wrong as on my 20 disk backup machine with 20 1TB disks on a single raidz2 vdev I get the following with DD on sequential reads/writes: writes: r...@opensolaris: 11:36 AM :/data# dd bs=1M count=10 if=/dev/zero of=./100gb.bin 10+0 records in 10+0 records

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 06/05/2010 01:08 PM, Bob Friesenhahn wrote: > > On Fri, 4 Jun 2010, Sandon Van Ness wrote: > >> >> >> >> The problem is that just using rsync I am not getting gigabit. For me >> >> gigabit maxes out at around 930-940 megabits. When I use rs

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 06/04/2010 06:15 PM, Bob Friesenhahn wrote: > On Fri, 4 Jun 2010, Sandon Van Ness wrote: >> >> Interesting enough when I went to copy the data back I got even worse >> download speeds than I did write speeds! It looks like i need some sort >> of read-ahead as unlike t

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 06/01/2010 07:57 AM, Bob Friesenhahn wrote: > On Mon, 31 May 2010, Sandon Van Ness wrote: >> With sequential writes I don't see how parity writing would be any >> different from when I just created a 20 disk zpool which is doing the >> same writes every 5 seconds but

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 05/31/2010 04:45 PM, Bob Friesenhahn wrote: > On Mon, 31 May 2010, Sandon Van Ness wrote: >> >> I think I have came to the conclusion that the problem here is CPU due >> to the fact that its only doing this with parity raid. I would think if >> it was I/O based then

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 05/31/2010 01:13 PM, Bob Friesenhahn wrote: > On Sun, 30 May 2010, Sandon Van Ness wrote: >> >> The problem is that when it does the write burst its taking away CPU >> usage from rsync which is actually what might be causing the dip during >> writes (not the I/O a

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 05/31/2010 02:52 PM, Mike Gerdts wrote: > On Mon, May 31, 2010 at 4:32 PM, Sandon Van Ness wrote: > >> On 05/31/2010 01:51 PM, Bob Friesenhahn wrote: >> >>> There are multiple factors at work. Your OpenSolaris should be new >>> enough to have the fi

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 05/31/2010 02:32 PM, Sandon Van Ness wrote: > well it seems like when messing with the txg sync times and stuff like > that it did make the transfer more smooth but didn't actually help with > speeds as it just meant the hangs happened for a shorter time but at a > smaller inte

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 05/31/2010 01:51 PM, Bob Friesenhahn wrote: > There are multiple factors at work. Your OpenSolaris should be new > enough to have the fix in which the zfs I/O tasks are run in in a > scheduling class at lower priority than normal user processes. > However, there is also a throttling mechanism f

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 05/31/2010 01:13 PM, Bob Friesenhahn wrote: > On Sun, 30 May 2010, Sandon Van Ness wrote: >> >> The problem is that when it does the write burst its taking away CPU >> usage from rsync which is actually what might be causing the dip during >> writes (not the I/O a

Re: [zfs-discuss] Disk space overhead (total volume size) by ZFS

evice Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 sd20 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: ST31000340AS Revision: SD14 Serial No: Size: 1000.20GB <1000204886016 bytes> Media Error: 0 Device Not Re

Re: [zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

On 05/30/2010 04:22 PM, Richard Elling wrote: > If you want to decouple the txg commit completely, then you might consider > using a buffer of some sort. I use mbuffer for pipes, but that may be tricky > to use in an rsync environment. > -- richard > I initially thought this was I/O but now I

Re: [zfs-discuss] Disk space overhead (total volume size) by ZFS

On 05/30/2010 03:10 PM, Mattias Pantzare wrote: > > On Sun, May 30, 2010 at 23:37, Sandon Van Ness wrote: > > > >> >> I just wanted to make sure this is normal and is expected. I fully >> >> expected that as the file-system filled up I would see mor

[zfs-discuss] Small stalls slowing down rsync from holding network saturation every 5 seconds

Basically for a few seconds at a time I can get very nice speeds through rsync (saturating a 1 gig link) which is around 112-113 megabytes/sec which is about as good as I can expect after overhead. The problem is that every 5 seconds when data is actually written to disks (physically looking at the

Re: [zfs-discuss] Disk space overhead (total volume size) by ZFS

On 05/30/2010 02:51 PM, Brandon High wrote: > On Sun, May 30, 2010 at 2:37 PM, Sandon Van Ness wrote: > >> ZFS: >> r...@opensolaris: 11:22 AM :/data# df -k /data >> > 'zfs list' is more accurate than df, since it will also show space > used by

[zfs-discuss] Disk space overhead (total volume size) by ZFS

I just wanted to make sure this is normal and is expected. I fully expected that as the file-system filled up I would see more disk space being used than with other file-systems due to its features but what I didn't expect was to lose out on ~500-600GB to be missing from the total volume size right