Re: [zfs-discuss] Legality and the future of zfs...

> "ab" == Alex Blewitt writes: >>> 3. The quality of software inside the firewire cases varies >>> wildly and is a big source of stability problems. (even on >>> mac) ab> It would be good if you could refrain from spreading FUD if ab> you don't have experience with it.

Re: [zfs-discuss] zfs destroy hangs machine if snapshot exists- workaround found

In any case, have you an idea of the way to solve my current problem? I have 450Gb in a deduped dataset I want to destroy, and each tentative I do results in a machine hang. I just want to destroy a dataset and all of its snapshots!! I tried unmounting before zfs destroy but had no luck... Thanks

Re: [zfs-discuss] Should i enable Write-Cache ?

> Instead, create "Single Disk" arrays for each disk. I have a question related to this but with a different controller: If I'm using a RAID controller to provide non-RAID single-disk volumes, do I still lose out on the hardware-independence advantage of software RAID that I would get from a ba

Re: [zfs-discuss] Should i enable Write-Cache ?

On 7/10/2010 1:14 AM, Graham McArdle wrote: Instead, create "Single Disk" arrays for each disk. I have a question related to this but with a different controller: If I'm using a RAID controller to provide non-RAID single-disk volumes, do I still lose out on the hardware-independence adva

Re: [zfs-discuss] Debunking the dedup memory myth

On Jul 9, 2010, at 11:10 PM, Brandon High wrote: > On Fri, Jul 9, 2010 at 5:18 PM, Brandon High wrote: > I think that DDT entries are a little bigger than what you're using. The size > seems to range between 150 and 250 bytes depending on how it's calculated, > call it 200b each. Your 128G data

Re: [zfs-discuss] Debunking the dedup memory myth

On 7/10/2010 5:24 AM, Richard Elling wrote: On Jul 9, 2010, at 11:10 PM, Brandon High wrote: On Fri, Jul 9, 2010 at 5:18 PM, Brandon High wrote: I think that DDT entries are a little bigger than what you're using. The size seems to range between 150 and 250 bytes depending on how it's cal

Re: [zfs-discuss] Debunking the dedup memory myth

On Jul 10, 2010, at 5:33 AM, Erik Trimble wrote: > On 7/10/2010 5:24 AM, Richard Elling wrote: >> On Jul 9, 2010, at 11:10 PM, Brandon High wrote: >> >> >>> On Fri, Jul 9, 2010 at 5:18 PM, Brandon High wrote: >>> I think that DDT entries are a little bigger than what you're using. The >>> si

Re: [zfs-discuss] Should i enable Write-Cache ?

On Jul 10, 2010, at 5:46 AM, Erik Trimble wrote: > On 7/10/2010 1:14 AM, Graham McArdle wrote: >>> Instead, create "Single Disk" arrays for each disk. >>> >> I have a question related to this but with a different controller: If I'm >> using a RAID controller to provide non-RAID single-disk

Re: [zfs-discuss] Debunking the dedup memory myth

On Sat, Jul 10, 2010 at 5:33 AM, Erik Trimble wrote: > Which brings up an interesting idea: if I have a pool with good random > I/O (perhaps made from SSDs, or even one of those nifty Oracle F5100 > things), I would probably not want to have a DDT created, or at least have > one that was very

Re: [zfs-discuss] Scrub extremely slow?

> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Hernan F > Subject: [zfs-discuss] Scrub extremely slow? Perhaps this is related? http://hub.opensolaris.org/bin/view/Community+Group+zfs/11 Zpool version 11, introduced "improved scrub performa

Re: [zfs-discuss] Legality and the future of zfs...

> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Peter Taps > > A few companies have already backed out of zfs > as they cannot afford to go through a lawsuit. Or, in the case of Apple, who could definitely afford a lawsuit, but choose to a

Re: [zfs-discuss] Debunking the dedup memory myth

> From: Richard Elling [mailto:rich...@nexenta.com] > > 4% seems to be a pretty good SWAG. Is the above "4%" wrong, or am I wrong? Suppose 200bytes to 400bytes, per 128Kbyte block ... 200/131072 = 0.0015 = 0.15% 400/131072 = 0.003 = 0.3% which would mean for 100G unique data = 153M to 312M ram.

Re: [zfs-discuss] Scrub extremely slow?

I tested with Bonnie++ and it reports about 200MB/s. The pool version is 22 (SunOS solaris 5.11 snv_134 i86pc i386 i86pc Solaris) I let the scrub run for hours and it was still at around 10MB/s. I tried to access an iSCSI target on that pool and it was really really slow (about 600KB/s!) while

Re: [zfs-discuss] Debunking the dedup memory myth

> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Brandon High > > Dedup is to > save space, not accelerate i/o. I'm going to have to disagree with you there. Dedup is a type of compression. Compression can be used for storage savings, and

Re: [zfs-discuss] Debunking the dedup memory myth

> > 4% seems to be a pretty good SWAG. > > Is the above "4%" wrong, or am I wrong? > > Suppose 200bytes to 400bytes, per 128Kbyte block ... > 200/131072 = 0.0015 = 0.15% > 400/131072 = 0.003 = 0.3% > which would mean for 100G unique data = 153M to 312M ram. > > Around 3G ram for 1Tb unique data,

Re: [zfs-discuss] Scrub extremely slow?

- Original Message - > I tested with Bonnie++ and it reports about 200MB/s. > > The pool version is 22 (SunOS solaris 5.11 snv_134 i86pc i386 i86pc > Solaris) > > I let the scrub run for hours and it was still at around 10MB/s. I > tried to access an iSCSI target on that pool and it was r

[zfs-discuss] Cache flush (or the lack of such) and corruption

Hi all I've been reading a lot of messages on this list about potential and actual corruption of a zpool due to cache flush problems and whatnot, and I find myself amazed. I just wonder how a zpool compares with a good old filesystem when it comes to filesystem errors. It seems several of the

Re: [zfs-discuss] Cache flush (or the lack of such) and corruption

On Jul 10, 2010, at 12:53 PM, Roy Sigurd Karlsbakk wrote: > Hi all > > I've been reading a lot of messages on this list about potential and actual > corruption of a zpool due to cache flush problems and whatnot, and I find > myself amazed. Why are you amazed? Storage devices have been losing d

Re: [zfs-discuss] Scrub extremely slow?

Too bad then, I can't afford a couple of SSDs for this machine as it's just a home file server. I'm surprised about the scrub speed though... This used to be a 4x500GB machine, to which I replaced the disks one by one. Resilver (about 80% full) took about 6 hours to complete - now it's twice the

Re: [zfs-discuss] Cache flush (or the lack of such) and corruption

- Original Message - > Depends on the failure mode. I've spent hundreds (thousands?) of hours > attempting to recover data from backup tape because of bad hardware, > firmware, > and file systems. The major difference is that ZFS cares that the data > is not > correct, while older file syst

Re: [zfs-discuss] Cache flush (or the lack of such) and corruption

On Sat, 10 Jul 2010, Roy Sigurd Karlsbakk wrote: I've been reading a lot of messages on this list about potential and actual corruption of a zpool due to cache flush problems and whatnot, and I find myself amazed. You should not be amazed. People only take their radio in for repair when it

Re: [zfs-discuss] Debunking the dedup memory myth

> From: Roy Sigurd Karlsbakk [mailto:r...@karlsbakk.net] > > increases the probability of arc/ram cache hit. So dedup allows you > to > > stretch your disk, and also stretch your ram cache. Which also > > benefits performance. > > Theoretically, yes, but there will be an overhead in cpu/memory tha

Re: [zfs-discuss] Cache flush (or the lack of such) and corruption

On 10-Jul-10, at 4:57 PM, Roy Sigurd Karlsbakk wrote: - Original Message - Depends on the failure mode. I've spent hundreds (thousands?) of hours attempting to recover data from backup tape because of bad hardware, firmware, and file systems. The major difference is that ZFS cares th

[zfs-discuss] zpool scrub is clean but still run in checksum errors when sending

'zpool scrub mypool' comes out clean. zfs send -Rv myp...@blah | ssh ... reports IO error. And indeed, 'zpool status -v' shows errors in some files in an older snapshot. Repeat scrub without errors and clear the pool. And send now fails on a different set of files. How can this happen? What w

Re: [zfs-discuss] zpool scrub is clean but still run in checksum errors when sending

This is the fourth time its happened. I had a clean scrub before starting send 15 minutes ago. And now, I see permanent errors in one of the files of one of the snapshots. Different file from last time. How do I find what's going on? 'dmesg' in guest or kernel does not have any relevant entrie

Re: [zfs-discuss] zpool scrub is clean but still run in checksum errors when sending

Funny thing is that if I enable the snapdir and 'cat' the file, it doesn't say IO error. -- 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] Debunking the dedup memory myth

Even the most expensive decompression algorithms generally run significantly faster than I/O to disk -- at least when real disks are involved. So, as long as you don't run out of CPU and have to wait for CPU to be available for decompression, the decompression will win. The same concept is true f

Re: [zfs-discuss] Debunking the dedup memory myth

On 7/10/2010 10:14 AM, Brandon High wrote: On Sat, Jul 10, 2010 at 5:33 AM, Erik Trimble > wrote: Which brings up an interesting idea: if I have a pool with good random I/O (perhaps made from SSDs, or even one of those nifty Oracle F5100 things), I

[zfs-discuss] Encryption?

I'm planning on running FreeBSD in VirtualBox (with a Linux host) and giving it raw disk access to four drives, which I plan to configure as a raidz2 volume. On top of that, I'm considering using encryption. I understand that ZFS doesn't yet natively support encryption, so my idea was to set e

Re: [zfs-discuss] SATA 6G controller for OSOL

Graham McArdle ccfe.ac.uk> writes: > > This thread from Marc Bevand and his blog linked therein might have some useful alternative suggestions. > http://opensolaris.org/jive/thread.jspa?messageID=480925 > I've bookmarked it because it's quite a handy summary and I hope he keeps updating it with

Re: [zfs-discuss] Encryption?

On Sun, Jul 11, 2010 at 11:51 AM, Michael Johnson wrote: > I'm planning on running FreeBSD in VirtualBox (with a Linux host) and giving > it raw disk access to four drives, which I plan to configure as a raidz2 > volume. > On top of that, I'm considering using encryption.  I understand that ZFS >