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