Re: [zfs-discuss] RFE: Un-dedup for unique blocks
On 01/22/2013 10:50 PM, Gary Mills wrote: On Tue, Jan 22, 2013 at 11:54:53PM +, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote: Paging out unused portions of an executing process from real memory to the swap device is certainly beneficial. Swapping out complete processes is a desperation move, but paging out most of an idle process is a good thing. It gets even better. Executables become part of the swap space via mmap, so that if you have a lot of copies of the same process running in memory, the executable bits don't waste any more space (well, unless you use the sticky bit, although that might be deprecated, or if you copy the binary elsewhere.) There's lots of awesome fun optimizations in UNIX. :) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Heavy write IO for no apparent reason
On 01/16/2013 10:25 PM, Peter Wood wrote: Today I started migrating file systems from some old Open Solaris servers to these Supermicro boxes and noticed the transfer to one of them was going 10x slower then to the other one (like 10GB/hour). What does dladm show-link show? I'm guessing one of your links is at 100mbps or at half duplex. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Has anyone used a Dell with a PERC H310?
On 01/07/2013 04:16 PM, Sašo Kiselkov wrote: PERC H200 are well behaved cards that are easy to reflash and work well (even in JBOD mode) on Illumos - they are essentially a LSI SAS 9211. If you can get them, they're one heck of a reliable beast, and cheap too! I've had trouble with one of those (Dell PERC H200) in a Z68X-UD3H-B3 motherboard. When it was inserted in any slot, the machine wouldn't power on. I put it in a Dell desktop I borrowed for a day and it worked there. Any idea as to what might be the trouble? Couldn't even get it working long enough to attempt to reflash its BIOS. The machine would power on for a few seconds and immediately turn off. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Repairing corrupted ZFS pool
On 11/16/2012 07:15 PM, Peter Jeremy wrote: I have been tracking down a problem with zfs diff that reveals itself variously as a hang (unkillable process), panic or error, depending on the ZFS kernel version but seems to be caused by corruption within the pool. I am using FreeBSD but the issue looks to be generic ZFS, rather than FreeBSD-specific. The hang and panic are related to the rw_enter() in opensolaris/uts/common/fs/zfs/zap.c:zap_get_leaf_byblk() The error is: Unable to determine path or stats for object 2128453 in tank/beckett/home@20120518: Invalid argument Is the pool importing properly at least? Maybe you can create another volume and transfer the data over for that volume, then destroy it? There are special things you can do with import where you can roll back to a certain txg on the import if you know the damage is recent. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Repairing corrupted ZFS pool
On 11/19/2012 12:03 PM, Peter Jeremy wrote: On 2012-Nov-19 11:02:06 -0500, Ray Arachelian r...@arachelian.com wrote: The damage exists in the oldest snapshot for that filesystem. Are you able to delete that snapshot? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Scrub and checksum permutations
On 10/26/2012 04:29 AM, Karl Wagner wrote: Does it not store a separate checksum for a parity block? If so, it should not even need to recalculate the parity: assuming checksums match for all data and parity blocks, the data is good. I could understand why it would not store a checksum for a parity block. It is not really necessary: Parity is only used to reconstruct a corrupted block, so you can reconstruct the block and verify the data checksum. But I can also see why they would: Simplified logic, faster identification of corrupt parity blocks (more usefull for RAIDZ2 and greater), and the general principal that all blocks are checksummed. If this was the case, it should mean that RAIDZ scub is faster than mirror scrub, which I don't think it is. So this post is probably redundant (pun intended) Parity is very simple to calculate and doesn't use a lot of CPU - just slightly more work than reading all the blocks: read all the stripe blocks on all the drives involved in a stripe, then do a simple XOR operation across all the data. The actual checksums are more expensive as they're MD5 - much nicer when these can be hardware accelerated. Also, on x86, there are SSE block operations that make XORing for a whole block a lot faster by doing a whole chunk at a time, so you don't need a loop to do it - not sure which ZFS implementations take advantage of these, but in the end XOR is not an expensive operation. MD5 is by several orders of magnitude. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Changing rpool device paths/drivers
On 10/03/2012 05:54 AM, Jim Klimov wrote: Hello all, It was often asked and discussed on the list about how to change rpool HDDs from AHCI to IDE mode and back, with the modern routine involving reconfiguration of the BIOS, bootup from separate live media, simple import and export of the rpool, and bootup from the rpool. The documented way is to reinstall the OS upon HW changes. Both are inconvenient to say the least. Any chance to touch /reconfigure, power off, then change the BIOS settings and reboot, like in the old days? Or maybe with passing -r and optionally -s and -v from grub like the old way we used to reconfigure Solaris? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Recover data after zpool create -f
On 08/20/2012 02:55 PM, Ernest Dipko wrote: Is there any way to recover the data within a zpool after a spool create -f was issued on the disks? We had a pool that contained two internal disks (mirrored) and we added a zvol to it our of an existing pool for some temporary space. After the reboot, the pool was not able to be imported because it could not find the zvol disk. Trying to import the pool and specifying a -d /dev/zvol/dsk/rpool actually found the zvol which contained the missing disk, but failed import with missing disks (the two internal). We then tried to recreate the pool, which was successful - but without data… Do this: Create a directory somewhere and make links (soft will work) to the devices that are in the pool, then pass the path to that dir to -d. -d expects a directory containing the devices, not the actual devices. Just learned this a week ago myself. :) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] How do I import a zpool with a file as a member device?
While attempting to fix the last of my damaged zpools, there's one that consists of 4 drives + one 60G file. The file happened by accident - I attempted to add a partition off an SSD drive but missed the cache keyword. Of course, once this is done, there's no way to remove the new unwanted member. I fixed this by creating a file with mkfile, and adding the file as a mirror of the SSD partition, then removed the SSD partition from the zpool and kept the file around. Over time something went wrong with this zpool and it hung the OS from booting, so I removed it from the machine, but held on to it so I could attempt to recover. I'm trying to recover it now, but when I try to import it without cache and read only, it tells me a member is missing (the file of course). But, how do I pass the file name as a member of the zpool to the import command? Since it's only 60g, I suppose I could dd the file over to an external USB drive. Would that work? Do I have to write it to slice 0, or a whole volume (slice 2)? I'm guessing this might be the path of least resistance... Or is there some hidden option to zpool import where you can pass it file/device names that I'm no aware of? (Attempting to use zpool online poolname /path/to/file doesn't work since the zpool isn't imported yet. Catch 22 there.) :) Otherwise, I do have a backup of the /etc/zfs/zpool.cache that contains references to this zpool, but it seems that this is corrupted and prevents all zpool operations. I've tried to replace the zpool members, but it won't let me. I've even used a hex editor to replace the device names in the zpool.cache file with the new device names, but it's still locked. So I can't use the zpool cache file as a way to point to the file member. Is there some way to clear the corrupted flag in the zpool.cache from allowing zpool commands to work? I'm on oi151a5, but this zpool was created around oi134/135 or so. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How do I import a zpool with a file as a member device?
On 08/13/2012 06:50 AM, Sašo Kiselkov wrote:
See the -d option to zpool import. -- Saso
Many thanks for this, it worked very nicely, though the first time I ran
it, it failed. So what -d does is to substitute /dev. In order for it
to work, you also have to make links to the drive devices in the /dev tree.
I did this in the directory where the file-members live (not knowing
exactly off the top of my head which types of devices/slices zfs wanted)
and then I was able to mount the pool, since the physical devices were
c22t0d4-d7:
for i in d4 d5 d6 d7; do for dev in /dev/dsk/c22t0${i}*; do echo $dev;
ln -s $dev; done; done
After this, using the -d option worked beautifully.
Thanks for helping me recover my data. :)
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] encfs on top of zfs
On 07/31/2012 09:46 AM, opensolarisisdeadlongliveopensolaris wrote: Dedup: First of all, I don't recommend using dedup under any circumstance. Not that it's unstable or anything, just that the performance is so horrible, it's never worth while. But particularly with encrypted data, you're guaranteed to have no duplicate data anyway, so it would be a pure waste. Don't do it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss One thing you can do is enable dedup when you copy all your data from one zpool to another, then, when you're done, disable dedup. It will no longer waste a ton of memory, and your new volume will have a high dedup ratio. (Obviously anything you add after you turn dedup off won't be deduped.) You can keep the old pool as a backup, or wipe it or whatever and later on do the same operation in the other direction. Anyone know if zfs send | zfs get will maintain the deduped files after this? Maybe once deduped you can wipe the old pool, then use get|send to get a deduped backup? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
