That webpage has one of the weirdest title images I've ever seen. I'm saving this for future reference; right now everything is ticking along very well and I am NOT messing with it! This machine (while not exactly weak) is using fairly cheap commodity components. I've had it long before I needed ZFS on there. It's an AMD A-series CPU and cheap ASUS motherboard, I'm fairly surprised (and happy!) it supports more than 16gigs of RAM! Honestly if I knew what a hassle ZFS would be I'd have probably gone with XFS... I honestly expect the ZFS array to last longer than the machine itself, and when I build a new server for it I'll probably get something better that supports ECC. for now, this'll have to do. On Tue, 11 Mar 2014, T L wrote: > > ZFS does "cache like crazy" to RAM and, in fact, you'll probably want to > limit that on most Linux boxen. See > > http://arstechnica.com/information-technology/2014/02/ars-walkthrough-using > -the-zfs-next-gen-filesystem-on-linux/ > Scroll down to the Initial Tuning section. > > Because of that and because if the way ZFS' checksumming works, you really, > really want ECC if you care about your data. > > Intel has made ECC available on some cheap CPUs. I think that the lowest is > $61 at retail. That said, I don't know of a 1150 ECC-friendly cheap > motherboard. > > I run an AMD FX six core processor with a cheap ASUS motherboard that both > do support ECC. The 10 drives in the box consume enough power that I'm not > worked up about the extra watts (50?) required by going with AMD instead of > Intel. > > Thomas > > On Mar 11, 2014 3:02 PM, "Jeremy MountainJohnson" > <jeremy.mountainjohnson at gmail.com> wrote: > Not sure on the distro you have, but with ZFSonLinux you don't > use fstab. For example, in Arch there is a service to handle > this if enabled at boot (part of the zfs package). The file > system mount point is configured with zfs user space tools, or > defaults to what you set originally when you created the volume. > > Also, curious on the ram problems. Arch, the distro I use, is tweaked > to be heavy on caching to RAM. So, often times when I am working with > extensive I/O and large files, 90% of memory will be dedicated to > caching in RAM and never touch swap (ext4, sw raid1). If I need that > cached RAM, it diverts it out of the cache automatically. The free > command shows how RAM is allocated. I'm no zfs expert, but perhaps zfs > is caching like crazy to RAM, although now that you're stable with > more RAM, this kinda debunks that. > > > -- > Jeremy MountainJohnson > Jeremy.MountainJohnson at gmail.com > > > On Tue, Mar 11, 2014 at 2:42 PM, <tclug at freakzilla.com> wrote: > Course I'm not using ECC RAM. This is a home system (: > > The data is... well, be nice if it didn't get corrupted, > but if a video file gets a small glitch in it, it's not a > huge deal. I can always rerip one disc if I need to. I > also figured that's why I have two smaller raidz1 (which > is equivalent to raid5, right?) pools - it should be able > to fix the occasional checksum error. > > I've not seen any crop up on this setup until that scrub, > which was after I copied and erased about 8TB a couple of > times. So not super worried. > > I can't really not use the filesystem during a scrub, > since a scrub takes over 24 hours. I could restrict it to > read-only. > > Hey, that reminds me, for some reason the thing mounts as > read-only when I reboot. And since it's not in fstab I > don't know where to fix that... anyone?... > > > > On Tue, 11 Mar 2014, Jake Vath wrote: > > > Now, I am seeing occasional checksum > errors. I stress-tested the > heck out of the thing for a week or so > (filled up the > filesystem, then deleted most the junk I > used for that, etc) and > when I ran a scrub it found 12 of them. > I'm assuming that since > I am running multiple redundancies that > that's not a huge > problem. Is this correct? Should I > cronjob a scrub once a month? > > Are you using ECC RAM? > If you're not, then you'll see some > checksumming/parity calculation errors. > Is this a huge problem? I guess it could be > when you consider how important > your data is to you. > Your ZPool(s) could get really screwed up if > you're getting checksumming > errors. > > A cronjob to scrub the system isn't a bad > idea, I guess you'd have to make > sure that nothing is going to try and use the > system during the scrubbing > process though. > > -> Jake > > > -> Jake > > > On Tue, Mar 11, 2014 at 2:24 PM, > <tclug at freakzilla.com> wrote: > This is a follow-up to my ZFS woes from > a month or so ago. > > Funny thing. When that machine had > 16gigs of RAM + 16gigs of > swap, it was using 15gig of RAM and not > touching swap at all, > and ZFS performace was horrible. > > So I threw another 16gigs of RAM in > there. > > Now it uses 20gigs of RAM (still not > touching swap, obviously) > and ZFS performance is fine. > > Now, I am seeing occasional checksum > errors. I stress-tested the > heck out of the thing for a week or so > (filled up the > filesystem, then deleted most the junk I > used for that, etc) and > when I ran a scrub it found 12 of them. > I'm assuming that since > I am running multiple redundancies that > that's not a huge > problem. Is this correct? Should I > cronjob a scrub once a month? > > I'm pretty gald I didn't need to move > away from ZFS... > > -- > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. > Paul, Minnesota > tclug-list at mn-linux.org > > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > >