Re: [zfs-discuss] Scrub and checksum permutations
Does it not store a separate checksum for a parity block? If so, it should not even need to recalculate the parity: assuming checksums match for all data and parity blocks, the data is good. I could understand why it would not store a checksum for a parity block. It is not really necessary: Parity is only used to reconstruct a corrupted block, so you can reconstruct the block and verify the data checksum. But I can also see why they would: Simplified logic, faster identification of corrupt parity blocks (more usefull for RAIDZ2 and greater), and the general principal that all blocks are checksummed. If this was the case, it should mean that RAIDZ scub is faster than mirror scrub, which I don't think it is. So this post is probably redundant (pun intended) On 2012-10-25 20:46, Jim Klimov wrote: > 2012-10-25 21:17, Timothy Coalson wrote: >> On Thu, Oct 25, 2012 at 7:35 AM, Jim Klimov > wrote: If scrubbing works the way we "logically" expect it to, it should enforce validation of such combinations for each read of each copy of a block, in order to ensure that parity sectors are intact and can be used for data recovery if a plain sector fails. Likely, raidzN scrubs should show as compute-intensive tasks compared to similar mirror scrubs. It should only be as compute intensive as writes - it can read the userdata and parity sectors, ensure the userdata checksum matches (reconstruct and do a fresh write in the rare cases it is not), and then recalculate the parity sectors from the verified user sectors, and compare them to the parity sectors it actually read. > Hmmm, that's another way to skin the cat, and it makes more sense ;) //Jim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org [2] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss [3] Links: -- [1] mailto:jimkli...@cos.ru [2] mailto:zfs-discuss@opensolaris.org [3] 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] Scrub and checksum permutations
2012-10-26 12:29, Karl Wagner wrote: Does it not store a separate checksum for a parity block? If so, it should not even need to recalculate the parity: assuming checksums match for all data and parity blocks, the data is good. No, for the on-disk sector allocation over M disks, zfs raidzN writes N parity sectors and up to M-N data sectors (may be less for small blocks and tails of blocks) for which that parity is, then repeats the process until it runs out of userdata sectors in the to-write buffer. Overall the parity and data sectors make up the on-disk block's contents. Matching the contents (plain userdata or permutations with parities) to the expected checksum of the logical block (of userdata) is what guarantees that the block was not corrupted - or that corruption was detected and repaired (or not). I am not sure how far permutations go however - does it try to repair per-stripe or per-column? If it tries hard, there are quite many combinations to try for a 128Kb block spread over 512b sectors in a raidz3 set ;) I could understand why it would not store a checksum for a parity block. To summarize, parities are not separate blocks. They are additional sectors prepended (and intermixed with) sectors of userdata, all together saved as the on-disk block. //Jim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] suggestions for e-SATA HBA card on x86/x64
I've been using this card http://www.newegg.com/Product/Product.aspx?Item=N82E16816117157 for my Solaris/Open Indiana installations because it has 8 ports. One of the issues that this card seems to have, is that certain failures can cause other secondary problems in other drives on the same SAS connector. I use mirrors for my storage machines with 4 pairs, and just put half the mirror on one side and the other drive on the other side. This, in general, has solved my problems. When a drive fails, I might see more than one drive no functioning. I can remove (I use hot swap bays such as http://www.newegg.com/Product/Product.aspx?Item=N82E16817994097) a drive, and restore the other to the pool to find which of the failed drives is actually the problem. What had happened before, was that my case was not moving enough air, and the hot drives had caused odd problems with failure. For the money, and the experience I have with these controllers, I'd still use them, they are 3GBs controllers. If you want 6GBs controllers, then some of the other suggestions might be a better choice for you. Gregg On Oct 24, 2012, at 10:59 PM, Jerry Kemp wrote: > I have just acquired a new JBOD box that will be used as a media > center/storage for home use only on my x86/x64 box running OpenIndiana > b151a7 currently. > > Its strictly a JBOD, no hw raid options, with an eSATA port to each drive. > > I am looking for suggestions for an HBA card with at least (2), but (4) > external eSATA ports would be nice. I know enough to stay away from the > port expander things. > > I do not need the HBA to support any internal drives. > > In reviewing the archives/past post, it seems that LSI is the way to go. > I would like to spend USD $200 - $300, but would spend more if > necessary for a good, trouble free HBA. I made this comment as I went > to look at some of the LSI cards previously mentioned, and found they > were priced $500 - $600 and up. > > TIA for any pointers, > > Jerry > ___ > 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] [Freenas-announce] FreeNAS 8.3.0-RELEASE
- Forwarded message from Josh Paetzel - From: Josh Paetzel Date: Fri, 26 Oct 2012 09:55:22 -0700 To: freenas-annou...@lists.sourceforge.net Subject: [Freenas-announce] FreeNAS 8.3.0-RELEASE User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The FreeNAS development team is pleased to announce the immediate availability of FreeNAS 8.3.0-RELEASE. Images and plugins can be downloaded from the following site: http://sourceforge.net/projects/freenas/files/FreeNAS-8.3.0/RELEASE/ FreeNAS 8.3.0 is based on FreeBSD 8.3 with version 28 of the ZFS filesystem. This is a major milestone in FreeNAS development, bringing in the plugin system with ZFS version 28. Development of the FreeNAS 8.2 branch has come to a halt, as both ZFS version 15 as well as FreeBSD 8.2 are no longer supported. There have been no major changes between 8.3.0-RC1 and RELEASE, mostly bugfixes and minor usability improvements to the GUI. See the release notes for a complete list: http://sourceforge.net/projects/freenas/files/FreeNAS-8.3.0/RC1/README/download The bug tracker for FreeNAS is available at http://support.freenas.org Discussion about FreeNAS occurs in the FreeNAS forums, located at: http://forums.freenas.org as well as in the official FreeNAS IRC channel on FreeNode in #freenas. - -- Thanks, Josh Paetzel Director of IT, iXsystems Servers For Open Source http://www.ixsystems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQisB6AAoJECFKQTJR8TNdPccH/0BWu5Soil8eurr7088azhfI qm1Euk/W2y0mvg7cC4PvzGclX8S7Lsd40fVYlr7u5igtdtbbbG9mR5SuonzG9IZY rqRwuNMdo67RUwSMXPvMG9uGx7FxrtOlrAkvQqFxpSl8TMKpfW93tgkKpDdaoeUz SSFaPon18hyKd/Ic9ZD/7I10d2t/pwfgbJ+XxljU/8pQrWtmyQZwrtm4GAOlogQ4 vrDa54HsvvwWx+CTAtlilSdbxbnYMbePzfZ2xMHP9LH/Zf58K3ok83j28LngffEX Bb0CjViXHXW+zOpK0LYsIIWC1igqwS05y5QAlFoc1P9tv0j5wfj9jhrn17A9lV8= =W0RS -END PGP SIGNATURE- -- The Windows 8 Center In partnership with Sourceforge Your idea - your app - 30 days. Get started! http://windows8center.sourceforge.net/ what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/ ___ Freenas-announce mailing list freenas-annou...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freenas-announce - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] suggestions for e-SATA HBA card on x86/x64
On Fri, 26 Oct 2012, Jerry Kemp wrote: Thanks for the SIIG pointer, most of the stuff I had archived from this list pointed to LSI products. I poked around on the site and reviewed SIIG's SATA and SAS HBA. I also hit up their search engine. I'm not implying I did an all inclusive search, but nothing I came across on their site indicated any type of Solaris or *Solaris distro support. What is important is if Solaris supports the card. I have no idea if Solaris supports any of their cards. Did I miss something on the site? Or maybe one of their sales people let you know this stuff worked with Solaris? Or should it "just work" as long as it meets SAS or SATA standards? They might not even know what Solaris is. Actually, they might since this outfit previously made the USB/FireWire combo card used in SPARC and Intel Sun workstations. It seems likely that SATA boards would work if they support the standard AHCI interface. I would not take any chance with unknown SAS. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, 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
[zfs-discuss] Zpool LUN Sizes
I'm creating a zpool that is 25TB in size. What are the recommendations in regards to LUN sizes? For example: Should I have 4 x 6.25 TB LUNS to add to the zpool or 20 x 1.25TB LUNs to add to the pool? Or does it depend on the size of the san disks themselves? Or should I divide the zpool up and make several smaller zpools? Thanks___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zpool LUN Sizes
On Sat, Oct 27, 2012 at 4:08 AM, Morris Hooten wrote: > I'm creating a zpool that is 25TB in size. > > What are the recommendations in regards to LUN sizes? > > For example: > > Should I have 4 x 6.25 TB LUNS to add to the zpool or 20 x 1.25TB LUNs to > add to the pool? > > Or does it depend on the size of the san disks themselves? More like "you shouldn't let the SAN mess with the disks and let zfs see the disks as JBOD". ... but then again, your SAN might not let you do that. So my suggestion is actually just present one huge 25TB LUN to zfs and let the SAN handle redundancy. Or if your SAN can't do it either, just let it give whatever-biggest-size LUN that it can, and simply use stripe on zfs side. > > Or should I divide the zpool up and make several smaller zpools? If you're going to use them for a single purpose anyway (e.g. storing database files from a single db, or whatever), I don't see the benefit in doing that. -- Fajar ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zpool LUN Sizes
Disclaimer: I haven't used LUNs with ZFS, so take this with a grain of salt. On Fri, Oct 26, 2012 at 4:08 PM, Morris Hooten wrote: > I'm creating a zpool that is 25TB in size. > > What are the recommendations in regards to LUN sizes? > The first standard advice I can give is that ZFS wants to be in charge of the redundancy, otherwise it can only tell you when there is a data error, but it can't fix it (other than possibly metadata copies, or if you set copies for data). So, if you can have the LUNs be real disks, or otherwise set up so that they reside on independent storage, something like a pool of raidz2 vdevs, or of mirror pairs, is the general idea to provide good data integrity. When ZFS detects data corruption, and it can't fix it (no redundancy or problems in too many of the constituent sectors to successfully reconstruct), it will return an I/O error, and not a "best effort" at what it thinks the data was, so beware insufficient redundancy. > For example: > > Should I have 4 x 6.25 TB LUNS to add to the zpool or 20 x 1.25TB LUNs to > add to the pool? > > Or does it depend on the size of the san disks themselves? > Without redundancy controlled by ZFS, I am unsure whether having multiple separate LUNs will change performance significantly, it probably depends most upon whether the LUNs actually perform independently (if saturating one doesn't make any other LUN significantly slower). When in doubt, benchmark. > Or should I divide the zpool up and make several smaller zpools? > Multiple storage zpools are not usually needed, one main point of ZFS is that you can have as many filesystems as you want on each pool. As for performance, zpool performance should, in theory, scale with the performance of the underlying devices, so two small zpools shouldn't be faster in aggregate than one large zpool. The recommended configuration will depend on how you intend to use it, and what your constraints are, which aren't clear. Tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
