--
--
--
--
--
--
OK… so I copied my entire Pictures folder by just dragging it over and launching iphoto from the iPhoto library icon (in the Pictures folder), everything seems to work…!How do I resize the ZFS volume/pool so I can throw more stuff in there? I think I read someplace that this wasn't possible through grabbing and resizing the partition borders in Disk Utility with the mouse. The main HFS+ part I DO reduce in size using that method though I assume.
--
I get absolutely woeful performance with a single physical disk being shared with HFS and ZFS.When a process is reading/writing with the HFS partition and another process is reading/writing with the ZFS partition on the same disk...test with a file a few gig in size...
OK, I have a brilliant idea: what about putting my system on an Express card solid state thing like this: http://www.youtube.com/watch?v=5irgXU_5XUEThen make my main hard disk ZFS?!
--
You suspect a hardware failure...
> just raidz or mirrors, but actual backups). Actually, I don't trust MacZFS
> with my critical data anymore, not since I lost a pool with all my data on it a
...but you're also blaming MacZFS...
> secondary JHFS+ backup (did I mention the paranoia about backups?). I tried
> scrubbing it from openindiana in a virtualbox, but even that kernel panicked
> (and at < 100K/second scrubbing speed, it would have taken months to finish).
...after having taken MacZFS completely out of the situation, and replaced it with the latest upstream code, which your hardware can't keep up with and then crashes on...
> I have since built a linux fileserver with ZFSonLinux, and now wish I had kept
> that original pool around longer before re-formatting so that I could explore
> the degraded pool in something that wouldn't crash so easily.
...and you think that the beta ZFS from another OS would be stable.
Did I read this correctly so far? I'm jumping in here so I'm sorry if I misunderstood.
Did you run a hardware QA on that system, such as http://memtest.org/ or http://www.memtestosx.org/ ? And I guess you weren't able to move your drives to another system to test the zpool there.
> I presume they will, but it will take months to find out; on this particular
> machine, it rarely panics, but when it does, I think it always comes from MacZFS
> with ClamXavSentry running.
>
> I don't know why ClamXavSentry always seems to trip over this bug; I figured
> that it was either scanning a file with a bad checksum (which I am starting to
> think always causes a panic?), or it was exercising the driver more.
Again, I'm popping in suddenly into this thread, and this time I'm just guessing in case anyone else knows more. Is it possible that there's a bug in MacZFS which is triggered when there's a single process which walks through the entire filesystem? I read a few years ago that there was a bug that had made a panic occur when a really large rsync process was run. An antivirus scanner might be similar behavior. I don't know if there is still such a bug; just asking the kernel hackers.
> I'll see what happens when I run a scrub; it is time for one anyway.
That's a good idea, but remember that a scrub operates on low level blocks, whereas a userspace app such as ClamAV operates on the POSIX layer. So it's a different code path.
> I don't blame MacZFS for losing the pool, only for panicking so much I could
> not do anything with it. The degraded pool was a raidz1, so in hindsight, I
Yeah that can be inconvenient, having a panic in order to save the data.
> - the kernel panics every few weeks. Even if it does not lose data on disk, if
> the computer can't stay on long enough to fix the pool or copy the data to
> another pool, then it is effectively lost (unless you have a PC that can recover
> it).
Well, you just get another OS for a temporary scrub, unless your hardware is broken as yours seems to have been.
> that MacZFS is a 6 year old alpha code release from Apple that has only been
> patched since - few engineers, no major development efforts, small user base,
What MacZFS is based on *was* an alpha from Apple, long ago, which was then subsequently stabilized and enhanced.
Anyway, in case it helps with your future endeavors, or in case you want to submit more information, there are wiki documents about dealing with kernel panics. Mainly this:
… ClamXavSentry … I don't know what technology it uses to listen for new and changed files …
BSD process name corresponding to current thread: ClamXavSentry
… performance with a single physical disk being shared with HFS and ZFS. …
--
--
Kernel panic file: