Date: Sun, 24 Mar 2013 14:26:10 -0400 From: Quartz <quartz@sneakertech.com> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS question Message-ID: <514F4542.7060100@sneakertech.com> In-Reply-To: <20130324153342.GA3687@icarus.home.lan> References: <20130321044557.GA15977@icarus.home.lan> <514AA192.2090006@sneakertech.com> <20130321085304.GB16997@icarus.home.lan> <20130324153342.GA3687@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
> I also confirmed that **reads** from the now-busted pool do block/wait > indefinitely Yeah, and that's the kicker. When my pool dies, I can't even check its status to figure out what the hell went wrong. >(for some reason people > think kill -9 will always cause a kernel to unlock/relinquish a thread, > which is not the case)). Oh believe me, from years of experience with linux/mac I wish it were true. >For whatever reason "ls -l /pool" did return > results, but I imagine these may be being returned from some caching > mechanism within the kernel (either VFS or ZFS ARC, not sure). I've noticed this too a couple times, but it only appears to happen for the top directory or so. Copy a folder with a lot of nested subfolders and then test with 'ls -R', that will kill it guaranteed. ______________________________________ it has a certain smooth-brained appeal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?514F4542.7060100>