Re: [zfs-discuss] Mysterious corruption with raidz2 vdev
I suspect this is a bug in raidz error reporting. With a mirror, each copy either checksums correctly or it doesn't, so we know which drives gave us bad data. With RAID-Z, we have to infer which drives have damage. If the number of drives returning bad data is less than or equal to the number of parity drives, we can both detect and correct the error. But if, say, three drives in a RAID-Z2 stripe return corrupt data, we have no way to know which drives are at fault -- there's just not enough information, and I mean that in the mathematical sense (fewer equations than unknowns). That said, we should enhance 'zpool status' to indicate the number of detected-but-undiagnosable errors on each RAID-Z vdev. Jeff Kevin wrote: > We'll try running all of the diagnostic tests to rule out any other issues. > > But my question is, wouldn't I need to see at least 3 checksum errors on the > individual devices in order for there to be a visible error in the top level > vdev? There doesn't appear to be enough raw checksum errors on the disks for > there to have been 3 errors in the same vdev block. Or am I not understanding > the checksum count correctly? > > > This message posted from opensolaris.org > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Trying to understand which kernel subsystem ZFS falls under.
Thank you for the reference to the ZFS overview document. > http://partneradvantage.sun.com/protected/solaris10/adoptionkit/tech/ > zfs/zfs_overview.pdf It's very useful and takes a different tack than the source tour, etc. There's a place for all of them. Could someone please place a link to this document or a copy of it at the OpenSolaris ZFS documentation at http://www.opensolaris.org/os/community/zfs/docs/ Thanks again, Eric ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs acls
I've been working with zfs since the beginning but have pretty much ignored ACL Inherit and ACL Mode. Now one of my DBs is having permission problems in a directory and has suggested changing the defaults Secure and Groupmask to passthrough. This would affect the whole filesystem. What would be the ramifications of this change? What might / would break? Thanks for any advice, help or links. Ron 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] Trying to understand which kernel subsystem ZFS falls under.
On 7/30/07, Brian Gupta <[EMAIL PROTECTED]> wrote: > I would think that ZFS would lie in the VFS subsystem VFS is just an interface between a filesystem and the rest of the kernel. > Could someone point me to a doc/diagram that would help clarify this for > me? See Figure 3: Traditional file system block diagram, vs. the ZFS block diagram http://partneradvantage.sun.com/protected/solaris10/adoptionkit/tech/zfs/zfs_overview.pdf And ZFS Source Tour: http://opensolaris.org/os/community/zfs/source/;jsessionid=7F5AA4C2F86A8CEC671D7B582DBB68DD Rayson ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Trying to understand which kernel subsystem ZFS falls under.
In "Solaris Internals", ZFS is not covered. I would think that ZFS would lie in the VFS subsystem, but I seem to recall reading that this is not the case. Could someone point me to a doc/diagram that would help clarify this for me? Thanks, Brian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Mysterious corruption with raidz2 vdev
Kevin wrote: > We'll try running all of the diagnostic tests to rule out any other issues. Does the server have ECC memory? Many x86 systems do not :-( > But my question is, wouldn't I need to see at least 3 checksum errors on the > individual devices in order for there to be a visible error in the top level > vdev? There doesn't appear to be enough raw checksum errors on the disks for > there to have been 3 errors in the same vdev block. Or am I not understanding > the checksum count correctly? You are assuming the corruption occured at the disk. That does not seem to be the case. ZFS checksums provide end-to-end data integrity. It will detect hard or transient errors along the entire data path. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Mysterious corruption with raidz2 vdev
We'll try running all of the diagnostic tests to rule out any other issues. But my question is, wouldn't I need to see at least 3 checksum errors on the individual devices in order for there to be a visible error in the top level vdev? There doesn't appear to be enough raw checksum errors on the disks for there to have been 3 errors in the same vdev block. Or am I not understanding the checksum count correctly? 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] 7zip compression?
MC <[EMAIL PROTECTED]> wrote: > On the heels of the LZO compression thread, I bring you a 7zip compression > thread! > > Shown here as the open source system with the best compression ratio: > http://en.wikipedia.org/wiki/Data_compression#Comparative > > Shown here on a SPARC system with the best compression ratios and good CPU > usage: http://warp.povusers.org/ArchiverComparison/ > > > Obviously 7zip is far more CPU-intensive than anything in use with ZFS today. > But maybe with all these processor cores coming down the road, a high-end > compression system is just the thing for ZFS to use. You would need a complete new clean C implementation for the algorithm. If someone would do this, I would be happy to also use the code for star ,-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS ant t3b
I have attached a "readable" txt format of the test. This message posted from opensolaris.orgVersion 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP ufs_cache_off 16G 22659 96 28608 31 709 1 21056 99 68828 78 504.0 9 ufs_cache_on16G 23289 98 78140 84 21509 42 21272 99 77029 87 830.2 15 ufs_directio16G 3711 20 9391 20 2287 7 8384 42 11955 17 660.9 7 zfs 16G 24383 98 86654 99 38173 72 22066 98 86612 79 794.5 11 zfs_compression 16G 26049 99 76441 88 39937 98 20058 99 101699 92 3254.3 191 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP ufs_cache_off16 1245 25 + +++ 1170 20 2163 21 + +++ 678 9 ufs_cache_on 16 2439 36 + +++ 2441 38 5316 71 + +++ 6529 88 ufs_directio 16 3710 66 + +++ 2453 46 5641 73 + +++ 6587 91 zfs 16 6377 99 + +++ 11079 99 6692 99 + +++ 11039 99 zfs_compression 16 6672 98 + +++ 12008 100 7207 100 + +++ 12165 99___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] 7zip compression?
Hello Marc, Sunday, July 29, 2007, 9:57:13 PM, you wrote: MB> MC eastlink.ca> writes: >> >> Obviously 7zip is far more CPU-intensive than anything in use with ZFS >> today. But maybe with all these processor cores coming down the road, >> a high-end compression system is just the thing for ZFS to use. MB> I am not sure you realize the scale of things here. Assuming the worst case: MB> that lzjb (default ZFS compression algorithm) performs as bad as lha in [1], MB> 7zip would compress your data only 20-30% better at the cost of being 4x-5x MB> slower ! MB> Also, in most cases, the bottleneck in data compression is the CPU, so MB> switching to 7zip would reduce the I/O throughput by about 4x. 1. it depends on a specific case - sometimes it's cpu sometimes not 2. sometimes you don't really care about cpu - you have hundreds TBs of data rarely used and then squeezing 20-30% more space is a huge benefit - especially when you only read those files once they are written -- Best regards, Robertmailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
