I'm trying to make it not be read-only, but I went: sterling at chimera:/home/sterling> sudo zfs get readonly NAME PROPERTY VALUE SOURCE media readonly off default So I think it's OK now. And if it ever starts happening again, I'll know what to look at (: On Tue, 11 Mar 2014, Linda Kateley wrote: > You put that in as an option to zfs > > #zfs set readonly=on filesystemname > > > On Tue, Mar 11, 2014 at 7:07 PM, <tclug at freakzilla.com> wrote: > That is cool, and I might end up doing that with this pool some > day. > > But is there somewhere where it specifies that the filesystem > should be mounted read-only? > > > On Tue, 11 Mar 2014, Linda Kateley wrote: > > 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 > > > _______________________________________________ > 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 > > > >