[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] ZFS on Linux



Is that not normal?  We need super redundant, ultra highly available, DR and you can use any 4 of these 5 year old machines to make it happen and meet our data storage needs!

Damon at damtek.com

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Jim Kinney
Sent: Friday, April 19, 2013 12:29 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] ZFS on Linux

given what the drive arrays are used for, dedup is a big plus (people make copies and copies of research files like drive space is $0!). And, yeah, even with no dedup, 32G is not going to cut it anyway.
The checksums for RAID6 are the same as in raidz2.
I found a 250G SSD but can't use it. I have one other system I can put it on but it has not enough PCIe slots for the need.
the solution to all of this is $$$$$ for new system :-(

On Fri, Apr 19, 2013 at 11:58 AM, Derek Atkins <warlord at mit.edu<mailto:warlord at mit.edu>> wrote:
Jim,

Jim Kinney <jim.kinney at gmail.com<mailto:jim.kinney at gmail.com>> writes:

> After much research, I have decided to NOT implement ZFS. The main factors of
> interest were the raidz2 and data deduplication. In order to support the
> deduplication,the server needs 5G RAM per 1TB storage. That's a deal breaker
> right there as the system to be used will only support 32G and has 50TB.
> Raidz2 is basically software RAID6 which I can already do.
>
> Looked at getting an SSD for the deduplication data and using l2arc but I have
> no space to install it on that server. Grr.
Do you really feel you need ZFS deduplication?  According to
http://doc.freenas.org/index.php/Hardware_Recommendations you only need
5GB/TB if you're using dedup.  If you're just using ZFS then they
recommend 1GB/TB.  Granted, if you've got 50TB of data then a 32GB
memory limit wont be useful to you.

However, thank you for making me look at that; I was considering a
32GB-limit Mobo for my system, which I was expecting to start at 12TB
usable but potentially expanding to 96TB.  I don't think a 96TB ZFS
would work well with 32GB memory.

OTOH, is ZFS really only just "RAID6"?  I thought that the ZFS checksums
would provide improved data integrity (scrubbing) over pure RAID6?

-derek

> On Fri, Mar 29, 2013 at 3:10 PM, Ed Cashin <ecashin at noserose.net<mailto:ecashin at noserose.net>> wrote:
>
>     Thanks in advance for the notes you take.  I'm interested to hear what you
>     find.
>
>     By the way, work sent me to a Nexenta course in 2010 where I learned ZFS
>     stuff from Richard Elling:
>
>       http://www.richardelling.com/
>
>     ... and one thing that kept coming up is how users usually reach for the
>     RAID-Z options when stripes of mirrors would perform better and offer more
>     flexibility.  I thought that was notable.
>
>     On Fri, Mar 29, 2013 at 2:44 PM, Jim Kinney <jim.kinney at gmail.com<mailto:jim.kinney at gmail.com>> wrote:
>
>         There was an update to this that just hit /.
>
>         WooHoo!
>
>         I have not used ZFS (minimal solaris experience) before but I have a
>         situation where raidz looks like a very good choice. An external 16
>         bay JBOD box hanging off a SAS HBA looks like a prime candidate. The
>         big issue for me is the support for native NFSv4 ACLs which solves
>         some issues.
>
>         As I go through this exercise, I'll keep some notes and maybe look at
>         a presentation on doing this.
>
>         hints, gotcha's, are very welcome.
>
>         I did find a pdf of the zfsadmin.pdf  http://pdfhome.org/zfsadmin.pdf
>
>         --
>         --
>         James P. Kinney III
>
>         Every time you stop a school, you will have to build a jail. What you
>         gain at one end you lose at the other. It's like feeding a dog on his
>         own tail. It won't fatten the dog.
>         - Speech 11/23/1900 Mark Twain
>
>         http://electjimkinney.org
>         http://heretothereideas.blogspot.com/
>
>         _______________________________________________
>         Ale mailing list
>         Ale at ale.org<mailto:Ale at ale.org>
>         http://mail.ale.org/mailman/listinfo/ale
>         See JOBS, ANNOUNCE and SCHOOLS lists at
>         http://mail.ale.org/mailman/listinfo
>
>     --
>       Ed Cashin <ecashin at noserose.net<mailto:ecashin at noserose.net>>
>       http://noserose.net/e/
>       http://www.coraid.com/
>
>     _______________________________________________
>     Ale mailing list
>     Ale at ale.org<mailto:Ale at ale.org>
>     http://mail.ale.org/mailman/listinfo/ale
>     See JOBS, ANNOUNCE and SCHOOLS lists at
>     http://mail.ale.org/mailman/listinfo
>
> --
> --
> James P. Kinney III
>
> Every time you stop a school, you will have to build a jail. What you gain at
> one end you lose at the other. It's like feeding a dog on his own tail. It
> won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
>
> http://electjimkinney.org
> http://heretothereideas.blogspot.com/
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org<mailto:Ale at ale.org>
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU<mailto:warlord at MIT.EDU>                        PGP key available
_______________________________________________
Ale mailing list
Ale at ale.org<mailto:Ale at ale.org>
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo



--
--
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you gain at one end you lose at the other. It's like feeding a dog on his own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://electjimkinney.org
http://heretothereideas.blogspot.com/
LEGAL DISCLAIMER
The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
By replying to this e-mail, you consent to SunTrust's monitoring activities of all communication that occurs on SunTrust's systems.
SunTrust is a federally registered service mark of SunTrust Banks, Inc.
[ST:XCL]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130419/96432c2f/attachment-0001.html>