Yea it's binary.. Only zfs can read it.. The cool thing is that if you use another server to read the pool, it will be able to build a new cache file for it.. lk On 3/11/14, 6:08 PM, tclug at freakzilla.com wrote: > 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 >> > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list