Finally, the expert (: Yeah, I have an /etc/zpool/zpool.cache, but it seems to be in a (mostly) binary format rather than an editable text file. I think last time I rebooted it came up read-write, so maybe that... resolved itself... which is cool but I wish I had a bit more info on what the heck was going on! On Tue, 11 Mar 2014, Linda Kateley wrote: > So yes zfs caches everything it can in the arc. Most distros have an arc max setting or some tunables for arc management. One of the easiest is setting primary-cache=metadata, that will tell zfs to only cache metadata. > > On Solaris there is file in /etc/zfs called zpool.cache. It functions similarily to the xxtab files in that if it exists it will be read in at boot and contains all device and filesystem info, but it differs in that if it doesn't exist it will be built with info from info on disks. > > Sent from my iPhone > >> On Mar 11, 2014, at 3:09 PM, tclug at freakzilla.com wrote: >> >> That's why I was asking (: Someone wake Linda up! >> >>> On Tue, 11 Mar 2014, Jake Vath wrote: >>> >>> Call me stupid, but I forgot we were talking about ZFS on Linux... you're >>> right. No fstab and no vfstab. >>> Sorry about that. >>> -> Jake >>> On Tue, Mar 11, 2014 at 3:01 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 >> _______________________________________________ >> 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 >