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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140311/822811dc/attachment.html>