Reputation
1,295
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
4 9
Newest
 Yearling
Impact
~72k people reached

Oct
31
comment Replacing a recovered hard disk in a ZFS pool
That scares the hell out of me, yet I can't think of any reason why it's a bad solution (other than remembering you did it so it doesn't bite you later). Good job? :)
Oct
31
comment ZFS Recover from Faulted Pool State
Is this pool imported or not? I'm guessing not, based on the output from your zpool replace (which I believe only can be run on an imported pool, or at least, I've never tried it on one not imported). You are correct to assume this SHOULD be recoverable. You've got a raidz1 with one faulty disk and at least per that status, no problems on other devices. However the pool level itself is claiming a 'corrupted data' error. I'm curious what 'zpool import tank' says?
Oct
31
answered iSCSI: LUNs per target?
Oct
11
comment ZFS: 3 devices: what's the difference between mirror and raidz2?
Oh, and with the 3-way mirror, you could also remove a disk later if you decided 3-way redundancy was too expensive. You cannot with a raidz or raidz2 vdev (you cannot alter the number of disks in a raidzX vdev once built).
Oct
11
answered ZFS: 3 devices: what's the difference between mirror and raidz2?
Oct
11
answered ZFS best practices with hardware RAID
Oct
11
comment zfs on a single device: what happens when a file is corrupted?
Is your question "are there ANY notable benefits to running ZFS as a filesystem on a single physical device" or "are there any notable DATA RESILIENCY benefits to running ZFS as a filesystem on a single physical device"? The answers are very different. The first is yes, the second is effectively no (other than using things like copies=, as others have already told you).
Oct
6
comment Force update checksum on zfs?
To further explain -- there is currently no way to zfs send|recv deduplicated data in such a way that all that goes across the wire is a single copy of the deduplicated data and the associated dedupe table entries. Not even if the source and destination are in sync and you're sending nothing more than an incremental snapshot. ZFS still balloons the send data up to full size if the data within it happens to be un-deduplicatable /within the scope of the stream itself/. You might have data that is easily deduped in the POOL DDT, but as a small send object, be completely un-deduplicatable.
Oct
6
comment Force update checksum on zfs?
zfs send | zfs recv will effectively change all metadata (compression choice, checksum choice, dedup choice). zfs send is creating an object that you then ingest using zfs recv, which writes it out pretty much as if it was all new data. However - I think you may be under a misconception about zfs send|recv in regards to deduplication. zfs send -D attempts to dedupe the data /within the stream itself/, not maintain the existing deduplication of the data from the source dataset. This is why there is no requirement that the recv side also have dedup enabled on the destination dataset.
Sep
14
comment ZFS Equivalent of lvdisplay snap_percent
In the case of a clone, you need to determine both how much space the clone itself has eaten up in delta from its origin snapshot -- and separately, you need to look and see how much delta the snapshot is holding due to changes in its parent. These are separate, I believe, and you'll need to look at both. Also a word of advice: when playing around with this, some people get confused running their own little test scenarios, because they don't realize the accounting is only updated during txg's - give it 10-30 seconds after committing any action to actually be accurately portrayed.
Sep
14
comment ZFS Equivalent of lvdisplay snap_percent
First, I tend to just use 'zpool list' to get an idea for actual disk usage. I do this because zpool list doesn't make allowances for reservation/refreservations and such, and is just telling you the % of the disks actually used. If that's not too high, I don't have to to any further accounting work. :) If it is, and I need to know, then it starts to be time to look at zfs list -o name,used,refer,avail,quota,refquota,reserv,refreserv,usedbysnapshot,usedbydatas‌​et,usedbychildren,usedbyrefreservation or something similar, and reading through it carefully.
Sep
14
comment ZFS Equivalent of lvdisplay snap_percent
@ewwhite's answer is to your question about monitoring snapshot delta/disk usage. A snapshot in ZFS is not a clone. A snapshot in ZFS does not act like a snapshot in LVM, either, and should not be thought of the same way. As for monitoring it, yes, you should keep an eye on overall pool usage. If your origin dataset has a lot of delta, the snapshots created on it will hold ever more blocks, eating up ever more space. If you start finding yourself approaching 80% on pool capacity, start destroying snapshots. Don't let a zpool get over 80% used if you can help it.
Sep
14
comment ZFS Equivalent of lvdisplay snap_percent
Do not confuse clones and snapshots. Snapshots are simply point in time holds on blocks - the only space they use is delta afterwards. CLONES, which are based off a snapshot but are now writeable, show up as new datasets equivalent to the parent of the snapshot -- eg: they'll be a new zvol or a new filesystem - not a snapshot themselves (in fact, you can then take snapshots of the clone, after you make it). Like snapshots, clone space usage is delta -- but in this case, it's delta it causes itself since it's writeable as opposed to delta between 'then & now' as with a snapshot.
Sep
14
comment How to fetch current l2arc_max_write setting on Illumos?
Tune it up slowly, looking for pain. It has been awhile since I last played with this, but as I recall the risk was that if the device couldn't eat the incoming flow quickly enough you pause all I/O or something equally horrendous (or at least, that's what I recall), so it is good to be conservative.
Sep
12
comment How large is my ZFS dedupe table at the moment?
I especially like @ewwhite's example DDT, because it also makes for a stellar example of a ratio that precludes using dedupe at all. I'd zfs send/recv the datasets on this pool, from deduped datasets to non-deduped datasets, and count myself lucky they were still small enough to make that manageable. :) Be careful assuming your zvols will dedupe. As a block-level dedupe, a single offset difference could skew the whole thing. If I have any advice, it is move mountains to test the production dataset in a TEST lab /before/ putting ZFS dedupe into any production environment.
Sep
12
answered How to fetch current l2arc_max_write setting on Illumos?
Sep
10
comment Best practices on VM disk management
For the record, probably the most common use-case for NexentaStor appliances is as the backing storage for virtualization (all hypervisors - VMware, Xen, KVM, etc). However, seemingly despite this but not actually, I agree with @ewwhite. Reason: in nearly all of those solutions, NexentaStor is running on separate hardware dedicated to its use, and then separate boxes running hypervisors with VM's on top talk to it. Nesting ZFS within the virtualization stack as opposed to under it is fraught with gotchyas, performance oddities and risk. It is /not/ impossible, but it is not turn key easy.
Sep
10
comment What is the purpose of /proc/config.gz
It can also be useful to determine if your kernel was actually compiled with support for something. If you know you need a specific feature, you can look in /proc/config.gz to determine its status in your kernel.
Aug
22
comment Sorting large binary files
You may be able to make use of either 'od' or 'hexdump' to finagle the data into something 'sort' can then better handle. Barring any example of the dataset, I can't be more helpful than that.
Aug
22
comment What are the performance implications of running VMs on a ZFS host?
Stefan's comment is .. well, it's just false. ZFS RAIDZ performance is significantly worse from an IOPS perspective (what you usually have issues with in VM's) than traditional RAID5 arrays. Please do not assume an improvement in write performance by moving to ZFS. It's rarely the case. Read perf gains will be dependent on RAM available to the ARC and your working set size and delta. Usually with VM's, ZFS ARC ends up helping with overall read performance compared to alternatives. Writes usually suffer, even on mirrors, ALWAYS with raidz.