I know how to set the mountpoint with ZFS - after all, it IS mounting - 
but I'm not sure why it's mounting read-only. I can go in and remount it 
in rw with no problem. And again, this is one of those "hey this just 
started happening..." things. It actually started when I tried using  PCI 
eSATA controller - thought that might help performance - but it couldn't 
handle the port multiplier, so I took it out. Since then, it mounts 
read-only.

I'm using Ubuntu server. I'm not sure what ZFS was/is doing with the RAM, 
but yeah, free (and top) were showing that the OS was using only 15gb of 
RAM. now that it has 32GB, it's using a lot more:

Mem:      32317820   19757248   12560572          0     234420    1027288

I guess it might be much to expect ZFS to go "Hey I neeeed more RAM!" 
but...

I got the filesystem up to 75% full, and it was still working just fine. 
And it took me days to fill it up THAT far, so I'm not worried about it 
getting that full anytime soon (I'm at 35% right now). And by then I can 
just... I dunno, build a new server for it (;


On Tue, 11 Mar 2014, Jeremy MountainJohnson 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
> 
> 
> 
>