Re: bug? ZFS crypto vs. scrub
On 11/05/2011 01:07, Daniel Carosone wrote: Sorry for abusing the mailing list, but I don't know how to report bugs anymore and have no visibility of whether this is a known/resolved issue. So, just in case it is not... Log a support call with Oracle if you have a support contract. With Solaris 11 Express, scrubbing a pool with encrypted datasets for which no key is currently loaded, unrecoverable read errors are reported. The error count applies to the pool, and not to any specific device, which is also somewhat at odds with the helpful message text for diagnostic status and suggested action: Known issue: 6989185 scrubbing a pool with encrypted filesystems and snapshots can report false positive errors. If you have a support contract you may be able to request that fix be back ported into an SRU (note I'm not guaranteeing it will be just saying that it is technically possible) When this has happened previously (on this and other pools) mounting the dataset by supplying the key, and rerunning the scrub, removes the errors. For some reason, I can't in this case (keeps complaining that the key is wrong). That may be a different issue that has also happened before, and I will post about separately, once I'm sure I didn't just made a typo (twice) when first setting the key. Since you are saying typo I'm assuming you have keysource=passphrase,prompt (ie the default). Have you ever done a send|recv of the encrypted datasets ? and if so where there multiple snapshots recv'd ? -- Darren J Moffat ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
RE: ZFS crypto source
I guessed you wouldn't be able to say, even if... The only shortfall in capability that I'm aware of is the secure boot/FDE, which we discussed previously. I am mostly interested in the source to see how features have been implemented and to understand the system structure. I certainly wouldn't presume to make changes! On the slightly more general topic of source on opensolaris, are the designs for subsystems/features available? I've found PSARC cases for some things but I expect that more detailed design, system interaction and use cases are documented as part of the development process. Are any of these types of document made public to assist in understanding at a higher level than the source code? Again, this is really to help me understand the system, rather than to attempt any modification. Regards Rob -Original Message- From: Darren J Moffat [mailto:darr...@opensolaris.org] Sent: 10 May 2011 11:17 To: Rob O'Leary Cc: zfs-crypto-discuss@opensolaris.org Subject: Re: ZFS crypto source On 07/05/2011 10:57, Rob O'Leary wrote: Is the source for ZFS crypto likely to be released on opensolaris.org? Older versions of the source area available from the zfs-crypto project gates: /zfs-crypto/gate/ However in some important areas these differ quite a bit from what was finally integrated and are not on disk compatible. I searched in /onnv/onnv-gate/usr/src/uts/common/fs/zfs, which may have been the wrong place, for aes and crypt and got no results so I assume that the zfs encryption has not been released to date. Correct the source has not been released. I do not know anything about future plans nor would I be able to comment here at this time even if I did. Please bring this up with your Oracle account/support team representative if it is important to your business. Is there something in particular you want to do with the source if you had it available to you ? Are there changes you want to make ? -- Darren J Moffat ___ zfs-crypto-discuss mailing list zfs-crypto-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss
Re: [zfs-discuss] Summary: Dedup and L2ARC memory requirements
Op 10-05-11 06:56, Edward Ned Harvey schreef: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Edward Ned Harvey BTW, here's how to tune it: echo arc_meta_limit/Z 0x3000 | sudo mdb -kw echo ::arc | sudo mdb -k | grep meta_limit arc_meta_limit= 768 MB Well ... I don't know what to think yet. I've been reading these numbers for like an hour, finding interesting things here and there, but nothing to really solidly point my finger at. The one thing I know for sure... The free mem drops at an unnatural rate. Initially the free mem disappears at a rate approx 2x faster than the sum of file size and metadata combined. Meaning the system could be caching the entire file and all the metadata, and that would only explain half of the memory disappearance. I'm seeing similar things. Yesterday I first rebooted with set zfs:zfs_arc_meta_limit=0x1 (that's 4 GiB) set in /etc/system and monitored while the box was doing its regular job (taking backups). zfs_arc_min is also set to 4 GiB. What I noticed is that shortly after the reboot, the arc started filling up rapidly, mostly with metadata. It shot up to: arc_meta_max = 3130 MB afterwards, the number for arc_meta_used steadily dropped. Some 12 hours ago, I started deleting files, it has deleted about 600 files since then. Now at the moment the arc size stays right at the minimum of 2 GiB, of which metadata fluctuates around 1650 MB. This is the output of the getmemstats.sh script you posted. Memory: 6135M phys mem, 539M free mem, 6144M total swap, 6144M free swap zfs:0:arcstats:c2147483648 = 2 GiB target size zfs:0:arcstats:c_max5350862848 = 5 GiB zfs:0:arcstats:c_min2147483648 = 2 GiB zfs:0:arcstats:data_size829660160 = 791 MiB zfs:0:arcstats:hdr_size 93396336= 89 MiB zfs:0:arcstats:other_size 411215168 = 392 MiB zfs:0:arcstats:size 1741492896 = 1661 Mi arc_meta_used = 1626 MB arc_meta_limit= 4096 MB arc_meta_max = 3130 MB I get way more cache misses then I'd like: Time read miss miss% dmis dm% pmis pm% mmis mm% arcszc 10:01:133K 380 10 1667 214 15 2597 1G 2G 10:02:132K 340 16372 302 46 323 16 1G 2G 10:03:132K 368 18473 321 46 347 17 1G 2G 10:04:131K 348 25444 303 63 335 24 1G 2G 10:05:132K 420 15874 332 36 383 14 1G 2G 10:06:133K 489 16 1326 357 35 427 14 1G 2G 10:07:132K 405 15492 355 39 401 15 1G 2G 10:08:132K 366 13402 326 37 366 13 1G 2G 10:09:131K 364 20181 345 58 363 20 1G 2G 10:10:134K 370 8592 311 21 3698 1G 2G 10:11:134K 351 8572 294 21 3508 1G 2G 10:12:133K 378 10592 319 26 372 10 1G 2G 10:13:133K 393 11532 339 28 393 11 1G 2G 10:14:132K 403 13402 363 35 402 13 1G 2G 10:15:133K 365 11482 317 30 365 11 1G 2G 10:16:132K 374 15402 334 40 374 15 1G 2G 10:17:133K 385 12432 341 28 383 12 1G 2G 10:18:134K 343 8642 279 19 3438 1G 2G 10:19:133K 391 10592 332 23 391 10 1G 2G So, one explanation I can think of is that the rest of the memory are l2arc pointers, supposing they are not actually counted in the arc memory usage totals (AFAIK l2arc pointers are considered to be part of arc). Then again my l2arc is still growing (slowly) and I'm only caching metadata at the moment, so you'd think it'd shrink if there's no more room for l2arc pointers. Besides I'm getting very little reads from ssd: capacity operationsbandwidth pool alloc free read write read write - - - - - - backups 5.49T 1.57T415121 3.13M 1.58M raidz1 5.49T 1.57T415121 3.13M 1.58M c0t0d0s1 - -170 16 2.47M 551K c0t1d0s1 - -171 16 2.46M 550K c0t2d0s1 - -170 16 2.53M 552K c0t3d0s1 - -170 16 2.44M 550K cache - - - - - - c1t5d0 63.4G 48.4G 20 0 2.45M 0 - - - - - - (typical statistic over 1 minute) I might try the windows solution and reboot the machine to free up memory and let it fill the cache all over again and see if I get more cache hits... hmmm... I set the
Re: [zfs-discuss] bootfs ID on zfs root
Technically bootfs ID is a string which names the root dataset, typically rpool/ROOT/solarisReleaseNameCode. This string can be passed to Solaris kernel as a parameter manually or by bootloader, otherwise a default current bootfs is read from the root pool's attributes (not dataset attributes! - see zpool get/set bootfs). In your case it seems that the attribute points to an invalid name, and your root dataset may be named somehing else - just set the pool attribute. I don't know of bootfs ID numbers, but maybe that's a concept in your company's scripting and patching environment. It is also possible that device names changed (i.e. on x86 - when SATA HDD access mode in BIOS changed from IDE to AHCI) and the boot device name saved in eeprom or its GRUB emulator is no longer valid. But this has different error strings ;) Good luck, //Jim -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Modify stmf_sbd_lu properties
You can try to workaround - no idea if this would really work - 0) Disable stmf and iscsi/* services 1) Create your volume's clone 2) Rename the original live volume dataset to some other name 3) Rename the clone to original dataset's name 4) Promote the clone - now for the system it SHOULD seem like this clone was always here with this original naming, and your current newer dataset is a cloned deviation. Hopefully this will fool STMF into using this data instead of new data, with existing GUID... 5) Enable stmf and iscsi/* services *) Tell us if it works ;) HTH, //Jim -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Performance problem suggestions?
Disks that have been in use for a longer time may have very fragmented free space on one hand, and not so much of it on another, but ZFS is still trying to push bits around evenly. And while it's waiting on some disks, others may be blocked as well. Something like that... This could explain why performance would go up after a large delete but I've not seen large wait times for any of my disks. The service time, percent busy, and every other metric continues to show nearly idle disks. I believe, in this situation the older fuller disks would show some activity and others can show zero or few IOs - because ZFS has no tasks for them. It sent a series of blocks to write from the queue, newer disks wrote them and stay dormant, while older disks seek around to fit that piece of data... When old disks complete the writes, ZFS batches them a new set of tasks. If this is the problem- it would be nice if there were a simple zfs or dtrace query that would show it to you. Well, it seems that the bridge between email and web interfaces to OpenSolaris forums has been fixed, for new posts at least, and hopefully Richard Elling or some other experts would come up with an idea of a dtrace for your situation. I have little non-zero hope that the experts would also come to the web-forums and review the past month's posts and give their comments to my, your and others' questions and findings ;) //Jim Klimov -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS backup and restore
Sorry, I did not hit this type of error... AFAIK the pool writes during zfs receive are done by current code (i.e. ZFSv22 for you) based on data read from the backup stream. So unless there are corruptions on the pool which happened to be at the same time as you did your restore, this procedure should not have broken your pool. It was just a (special) write by your OS version's code, nearly same as any other. Did you have any hardware problems at that time, like brown-outs, overheating, occasional push of a reset button? Maybe some experts here would be able to comment better or guide you through troubleshooting and collecting data, if you post your OS version details, error messages especially, etc. For example, if for some reason your hostid changed (i.e. you used the safe mode miniroot) and the pool tank was not exported afterwards, the error may be like Pool is busy or used by another system with a solution as simple as that you'd have to do a forced import (zpool import -f tank) - if it is indeed a local non-networked pool and no other machine really uses it. HTH, //Jim -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS backup and restore
Hi, Thanks for the response, Here is my problem. I have a zfs stream back up took on zfs version 15, currently i have upgraded my OS, so new zfs version is 22. Restore process went well from old stream backup to new zfs pool. but on reboot i got error unable to mount pool tank. So there is incompatibilities between zfs versions, especially send/receive. So looking for alternate backup solutions. Thanks kumar -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Performance problem suggestions?
Keep in mind zfs_vdev_max_pending. In the latest version of S10, this is set to 10. ZFS will not issue more than the value of this variable requests at a time for a LUN. Your disks may look relatively idle while ZFS has a lot of data piled up inside just waiting to be read or written. I have tweaked this on the fly. One key indicator is if your disk queues hover around 10. Jim --- - Original Message - From: jimkli...@cos.ru To: zfs-discuss@opensolaris.org Sent: Wednesday, May 11, 2011 3:22:19 AM GMT -08:00 US/Canada Pacific Subject: Re: [zfs-discuss] Performance problem suggestions? Disks that have been in use for a longer time may have very fragmented free space on one hand, and not so much of it on another, but ZFS is still trying to push bits around evenly. And while it's waiting on some disks, others may be blocked as well. Something like that... This could explain why performance would go up after a large delete but I've not seen large wait times for any of my disks. The service time, percent busy, and every other metric continues to show nearly idle disks. I believe, in this situation the older fuller disks would show some activity and others can show zero or few IOs - because ZFS has no tasks for them. It sent a series of blocks to write from the queue, newer disks wrote them and stay dormant, while older disks seek around to fit that piece of data... When old disks complete the writes, ZFS batches them a new set of tasks. If this is the problem- it would be nice if there were a simple zfs or dtrace query that would show it to you. Well, it seems that the bridge between email and web interfaces to OpenSolaris forums has been fixed, for new posts at least, and hopefully Richard Elling or some other experts would come up with an idea of a dtrace for your situation. I have little non-zero hope that the experts would also come to the web-forums and review the past month's posts and give their comments to my, your and others' questions and findings ;) //Jim Klimov -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Modify stmf_sbd_lu properties
I can't actually disable the STMF framework to do this but I can try renaming things and dumping the properties from one device to another and see if it works- it might actually do it. I will let you know. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Backup complete rpool structure and data to tape
Hello, Trying to understand how to backup mirrored zfs boot pool 'rpool' to tape, and restore it back if in case the disks are lost. Backup would be done with an enterprise tool like tsm, legato etc. As an example, here is the layout: # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool64.5G 209G97K legacy rpool/ROOT 24.0G 209G21K legacy rpool/ROOT/s10s_u8wos_08a 24G 14.8G 5.15G / rpool/ROOT/s10s_u8wos_08a/var 4G 3.93G 74.6M /var rpool/dump 2.50G 209G 2.50G - rpool/swap 16G 225G 136M - # Could you answer these queries: 1. Is it possible to backup 'rpool' as a single entity, or do we need to backup each filesystems, volumes etc. within rpool seperately ? 2. How do we backup the whole structure of zfs (pool, filesystem, volume, snapshot etc.) along with all its property settings. Not just the actual data stored within. 3. If in case the whole structure cannot be backed up using enterprise backup, how do we save and restore zfs sctructure if in case the disks are lost. I have read about 'zfs send receive ...'. Is this the only recommended way ? 4. I have never tried to restore a whole boot disk from tape. Could you share some details on how to rebuild the boot disks by restoring from tape. 5. I have set 'rpool/ROOT' mountpoint to 'legacy' as I don't see any reason to mount it. Not sure if it's a right thing to do. Any suggestions ? Thanks Arjun ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Modify stmf_sbd_lu properties
On 05/10/11 09:45 PM, Don wrote: Is it possible to modify the GUID associated with a ZFS volume imported into STMF? To clarify- I have a ZFS volume I have imported into STMF and export via iscsi. I have a number of snapshots of this volume. I need to temporarily go back to an older snapshot without removing all the more recent ones. I can delete the current sbd LU, clone the snapshot I want to test, and then bring that back in to sbd. The problem is that you need to use sbdadm create-lu and that creates a new GUID. (sbdadm import-lu on a clone will give you a metafile error). Hi, maybe this could do: stmfadm create-lu -p guid=XXX.. Regards, ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Performance problem suggestions?
It sent a series of blocks to write from the queue, newer disks wrote them and stay dormant, while older disks seek around to fit that piece of data... When old disks complete the writes, ZFS batches them a new set of tasks. The thing is- as far as I know the OS doesn't ask the disk to find a place to fit the data. Instead the OS tracks what space on the disk is free and then tells the disk where to write the data. Even if ZFS was waiting for the IO to complete I would expect to see that delay reflected in the disk service times. In our case we see no high service times, no busy disks, nothing. It seems like ZFS is just sitting there quietly and thinking to itself. If the processor were busy that might make sense but even there- our processor seems largely idle. At the same time- even a scrub on this system is a joke right now and that's a read intensive operation. I'm seeing a scrub speed of 400K/s but almost no IO's to my disks. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Intel Z68 chipset and SSD 311 (Larson Creek)
The press embargo on Intel Z68 chipset has been lifted and so there's a bunch of press on it. One feature called Smart Response Technology (SRT) will sound familiar to users of ZFS: Intel's SRT functions like an actual cache. Rather than caching individual files, Intel focuses on frequently accessed LBAs (logical block addresses). Read a block enough times or write to it enough times and those accesses will get pulled into the SSD cache until it's full. When full, the least recently used data gets evicted making room for new data. http://www.anandtech.com/show/4329/2 In addition to the chipset (already shipping in the 2011 Apple iMacs), there's also an SLC SSD: The big difference here is the SSD 311 comes with 20GB of 34nm SLC NAND. If you remember back to the SSD Anthology, SLC NAND is architecturally identical to MLC NAND. With half the number of data stored per NAND cell SLC NAND not only lasts longer than MLC NAND but it also is much faster, particularly for writes. [...] The SSD 311 basically offers the performance of a 160GB X25-M G2 but with fewer NAND channels and a much lower capacity. Remember this is SLC NAND so despite only being a 20GB drive, it's priced more like a 40GB MLC drive: Intel expects the SSD 311 to retail for $110. Thankfully you aren't locked in to only using Intel drives as Smart Response Technology will work with any SSD. http://www.anandtech.com/show/4329/3 Some good pros and cons from Tom's Hardware of this system: http://tinyurl.com/42rzkyz http://www.tomshardware.com/reviews/intel-z68-express-smart-response-technology-ssd-caching,2938-3.html Plenty of other articles on the subject popping up. I think that the fact that the SSD is SLC and not too expensive would make it useful for ZFS users as well. Given that the ZIL can never be more than half of RAM, it would mean that you could put one in a server that has 40 GB of RAM. Or in a home machine that has, say, only 8 GB you could partition 4 GB of the SSD for a 'slog' device, and the rest for L2ARC cache. In a perfect world it'd have a supercap, but as it stands, I think it's a good addition to the product choices we have. Hopefully more manufacturers will get on the bandwagon of small SLC SSDs now that Intel is helping mainstream this idea by putting it right in their chipsets. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS backup and restore
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Naveen surisetty I have a zfs stream back up took on zfs version 15, currently i have upgraded my OS, so new zfs version is 22. Restore process went well from old stream backup to new zfs pool. but on reboot i got error unable to mount pool tank. Let me make sure I get this straight ... You did zfs send on zpool version 15, save to a file. Then you upgraded system and have zpool version 22. You do zfs receive and there are no errors. Simply having successfully completed the zfs receive should guarantee it was successfully received. But since you're having a problem, I suggest you zpool export and zpool import immediately after doing your zfs receive. If you're able to do this, it guarantees the pool is in fact importable. Then if you reboot and encounter a problem, you know you're running into something else that's weird. Like perhaps unsupported or buggy hardware that does something bad to disk during the reboot process. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Backup complete rpool structure and data to tape
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Arjun YK Trying to understand how to backup mirrored zfs boot pool 'rpool' to tape, and restore it back if in case the disks are lost. Backup would be done with an enterprise tool like tsm, legato etc. Backup/restore of bootable rpool to tape with a 3rd party application like legato etc is kind of difficult. Because if you need to do a bare metal restore, how are you going to do it? The root of the problem is the fact that you need an OS with legato in order to restore the OS. It's a catch-22. It is much easier if you can restore the rpool from some storage that doesn't require the 3rd party tool to access it ... I might suggest: If you use zfs send to backup rpool to a file in the data pool... And then use legato etc to backup the data pool... If you need to do a bare metal restore some day, you would just install a new OS, install legato or whatever, and restore your data pool. Then you could boot to a command prompt of the installation disc, and restore (obliterate) the rpool using the rpool backup file. But I hope you can completely abandon the whole 3rd party backup software and tapes. Some people can, and others cannot. By far, the fastest best way to backup ZFS is to use zfs send | zfs receive on another system or a set of removable disks. ZFS send has the major advantage that it doesn't need to crawl the whole filesystem scanning for changes. It just knows what incremental blocks have changed, and it instantly fetches only the necessary blocks. 1. Is it possible to backup 'rpool' as a single entity, or do we need to backup each filesystems, volumes etc. within rpool seperately ? You can do it either way you like. Specify a single filesystem, or recursively do all of its children. man zfs send 2. How do we backup the whole structure of zfs (pool, filesystem, volume, snapshot etc.) along with all its property settings. Not just the actual data stored within. Regarding pool filesystem properties, I believe this changed at some point. There was a time in history when I decided to zpool get all mypool and zfs get all mypool and store those text files alongside the backup. But if you check the man page for zfs send, I think this is automatic now. No matter what, you'll have to create a pool before you can restore. So you'll just have to take it upon yourself to remember your pool architecture ... striping, mirroring, raidz, cache log devices etc. Incidentally, when you do incremental zfs send, you have to specify the from and to snapshots. So there must be at least one identical snapshot in the sending and receiving system (or else your only option is to do a complete full send.) Point is: You can take a lot of baby steps if you wish, keeping all the snapshots if you wish. Or you can jump straight from the oldest matching snapshot to the latest snap. You'll complete somewhat faster but lose granularity in the backups if you do that. 3. If in case the whole structure cannot be backed up using enterprise backup, how do we save and restore zfs sctructure if in case the disks are lost. I have read about 'zfs send receive ...'. Is this the only recommended way ? For anything other than rpool, you can use any normal backup tool you like. Netbackup, legato, tar, cpio. Whatever. (For rpool, I wouldn't really trust those - I recommend zfs send for rpool.) You can also use zfs send receive for data pools. You gain performance (potentially many orders of magnitude shorter backup window) if zfs send receive are acceptable in your environment. But it's not suitable for everyone for many reasons... You can't exclude anything from zfs send... And you can't do a selective zfs receive. It's the whole filesystem or nothing. And a single bit corruption will render the whole backup unusable, so it's not recommended to store a zfs send data stream for later use. It's recommended to pipe a zfs send directly into a zfs receive. Which implies disk-to-disk, no tape. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS backup and restore
On May 10, 2011, at 11:21 PM, Naveen surisetty wrote: Hi, Thanks for the response, Here is my problem. I have a zfs stream back up took on zfs version 15, currently i have upgraded my OS, so new zfs version is 22. Restore process went well from old stream backup to new zfs pool. but on reboot i got error unable to mount pool tank. There is no such thing as mounting a pool Can you post the exact error message? -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Backup complete rpool structure and data to tape
* Edward Ned Harvey (opensolarisisdeadlongliveopensola...@nedharvey.com) wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Arjun YK Trying to understand how to backup mirrored zfs boot pool 'rpool' to tape, and restore it back if in case the disks are lost. Backup would be done with an enterprise tool like tsm, legato etc. Backup/restore of bootable rpool to tape with a 3rd party application like legato etc is kind of difficult. Because if you need to do a bare metal restore, how are you going to do it? The root of the problem is the fact that you need an OS with legato in order to restore the OS. It's a If you're talking about Solaris 11 Express, you could create your own liveCD using the Distribution Constructor[1] and include the backup software on the cd image. You'll have to customize the Distribution Constructor to install the backup software (presumably via an SVR4 package[2]) but that's not too difficult. Once you've created the image, you're good to go forevermore (unless you need to update the backup software on the image, in which case if you keep your Distribution Constructor manifests around should be a simple edit to just point at the newer backup software package).. If you're talking about S10, then that's a tougher nut to crack. Cheers, -- Glenn [1] - http://download.oracle.com/docs/cd/E19963-01/html/820-6564/ [2] - http://download.oracle.com/docs/cd/E19963-01/html/820-6564/addpkg.html ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] bootfs ID on zfs root
So y my system is not coming up .. i jumpstarted the system again ... but it panics like earlier .. so how should i recover it .. and get it up ? System was booted from network into single user mode and then rpool imported and following is the listing # zpool list NAMESIZE ALLOC FREECAP HEALTH ALTROOT rpool68G 4.08G 63.9G 5% ONLINE - # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 9.15G 57.8G98K /rpool rpool/ROOT4.08G 57.8G21K /rpool/ROOT rpool/ROOT/zfsBE_patched 4.08G 57.8G 4.08G / rpool/dump3.01G 60.8G16K - rpool/swap2.06G 59.9G16K - # Dataset mos [META], ID 0, cr_txg 4, 137K, 62 objects Dataset rpool/ROOT/zfsBE_patched [ZPL], ID 47, cr_txg 40, 4.08G, 110376 objects Dataset rpool/ROOT [ZPL], ID 39, cr_txg 32, 21.0K, 4 objects Dataset rpool/dump [ZVOL], ID 71, cr_txg 74, 16K, 2 objects Dataset rpool/swap [ZVOL], ID 65, cr_txg 71, 16K, 2 objects Dataset rpool [ZPL], ID 16, cr_txg 1, 98.0K, 10 objects But when system is rebooted it again panics .. Is there any way to recover it ? I tried all the things which i know SunOS Release 5.10 Version Generic_142900-13 64-bit Copyright 1983-2010 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. NOTICE: zfs_parse_bootfs: error 48 Cannot mount root on rpool/47 fstype zfs panic[cpu0]/thread=180e000: vfs_mountroot: cannot mount root -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] bootfs ID on zfs root
Hi Ketan, What steps lead up to this problem? I believe the boot failure messages below are related to a mismatch between the pool version and the installed OS version. If you're using the JumpStart installation method, then the root pool is re-created each time, I believe. Does it also install a patch that upgrades the pool version? Thanks, Cindy On 05/11/11 13:27, Ketan wrote: So y my system is not coming up .. i jumpstarted the system again ... but it panics like earlier .. so how should i recover it .. and get it up ? System was booted from network into single user mode and then rpool imported and following is the listing # zpool list NAMESIZE ALLOC FREECAP HEALTH ALTROOT rpool68G 4.08G 63.9G 5% ONLINE - # zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 9.15G 57.8G98K /rpool rpool/ROOT4.08G 57.8G21K /rpool/ROOT rpool/ROOT/zfsBE_patched 4.08G 57.8G 4.08G / rpool/dump3.01G 60.8G16K - rpool/swap2.06G 59.9G16K - # Dataset mos [META], ID 0, cr_txg 4, 137K, 62 objects Dataset rpool/ROOT/zfsBE_patched [ZPL], ID 47, cr_txg 40, 4.08G, 110376 objects Dataset rpool/ROOT [ZPL], ID 39, cr_txg 32, 21.0K, 4 objects Dataset rpool/dump [ZVOL], ID 71, cr_txg 74, 16K, 2 objects Dataset rpool/swap [ZVOL], ID 65, cr_txg 71, 16K, 2 objects Dataset rpool [ZPL], ID 16, cr_txg 1, 98.0K, 10 objects But when system is rebooted it again panics .. Is there any way to recover it ? I tried all the things which i know SunOS Release 5.10 Version Generic_142900-13 64-bit Copyright 1983-2010 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. NOTICE: zfs_parse_bootfs: error 48 Cannot mount root on rpool/47 fstype zfs panic[cpu0]/thread=180e000: vfs_mountroot: cannot mount root ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Modify stmf_sbd_lu properties
It turns out this was actually as simple as: stmfadm create-lu -p guid=XXX.. I kept looking at modify-lu to change this and never thought to check the create-lu options. Thanks to Evaldas for the suggestion. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Backup complete rpool structure and data to tape
On 2011-May-12 00:20:28 +0800, Edward Ned Harvey opensolarisisdeadlongliveopensola...@nedharvey.com wrote: Backup/restore of bootable rpool to tape with a 3rd party application like legato etc is kind of difficult. Because if you need to do a bare metal restore, how are you going to do it? This is a generic problem, not limited to ZFS. The generic solutions are either: a) Customised boot disk that includes the 3rd party restore client b) Separate backup of root+client in a format that's restorable using tools only on the generic boot disk (eg tar or ufsdump). (Where boot disk could be network boot instead of a physical CD/DVD). I might suggest: If you use zfs send to backup rpool to a file in the data pool... And then use legato etc to backup the data pool... As Edward pointed out later, this might be OK as a disaster-recovery approach but isn't suitable for the situation where you want to restore a subset of the files (eg you need to recover a file someone accidently deleted) and a zfs send stream isn't intended for storage. Another potential downside is that the only way to read the stream is using zfs recv into ZFS - this could present a problem if you wanted to migrate the data into a different filesystem. (All other restore utilities I'm aware of use normal open/write/chmod/... interfaces so you can restore your backup into any filesystem). Finally, the send/recv protocol is not guaranteed to be compatible between ZFS versions. I'm not aware of any specific issues (though someone reports that a zfs.v15 send | zfs.v22 recv caused pool corruption in another recent thread) and would hope that zfs recv would always maintain full compatibility with older zfs send. But I hope you can completely abandon the whole 3rd party backup software and tapes. Some people can, and others cannot. By far, the fastest best way to backup ZFS is to use zfs send | zfs receive on another system or a set of removable disks. Unfortunately, this doesn't fit cleanly into the traditional enterprise backup solution where Legato/NetBackup/TSM/... backs up into a SILO with automatic tape replication and off-site rotation. Incidentally, when you do incremental zfs send, you have to specify the from and to snapshots. So there must be at least one identical snapshot in the sending and receiving system (or else your only option is to do a complete full send.) And (at least on v15) if you are using an incremental replication stream and you create (or clone) a new descendent filesystem, you will need to manually manage the initial replication of that filesystem. BTW, if you do elect to build a bootable, removable drive for backups, you should be aware that gzip compression isn't supported - at least in v15, trying to make a gzip compressed filesystem bootable or trying to set compression=gzip on a bootable filesystem gives a very uninformative error message and it took a fair amount of trawling through the source code to find the real cause. -- Peter Jeremy pgpnNCrRwuYrc.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] bootfs ID on zfs root
Hello Jim, Thanks for the reply following is my o/p before setting bootfs parameter # zpool get all rpool NAME PROPERTY VALUE SOURCE rpool size 68G - rpool capacity 5%- rpool altroot- default rpool health ONLINE- rpool guid 8812174757237060985 default rpool version22default rpool bootfs rpool/ROOT/zfsBE_patched local rpool delegation ondefault rpool autoreplaceoff default rpool cachefile - default rpool failmode continue local rpool listsnapshots ondefault rpool autoexpand off default rpool free 63.9G - rpool allocated 4.08G - But i still ran the command .. but it didn't help me and system still panics # zpool set bootfs=rpool/ROOT/zfsBE_patched rpool # zpool get all rpool NAME PROPERTY VALUE SOURCE rpool size 68G - rpool capacity 5%- rpool altroot- default rpool health ONLINE- rpool guid 8812174757237060985 default rpool version22default rpool bootfs rpool/ROOT/zfsBE_patched local rpool delegation ondefault rpool autoreplaceoff default rpool cachefile - default rpool failmode continue local rpool listsnapshots ondefault rpool autoexpand off default rpool free 63.9G - rpool allocated 4.08G - # init 6 # The system is being restarted. syncing file systems... done rebooting... Resetting... POST Sequence 01 CPU Check POST Sequence 02 Banner LSB#00 (XSB#00-0): POST 2.14.0 (2010/05/13 13:27) POST Sequence 03 Fatal Check POST Sequence 04 CPU Register POST Sequence 05 STICK POST Sequence 06 MMU POST Sequence 07 Memory Initialize POST Sequence 08 Memory POST Sequence 09 Raw UE In Cache POST Sequence 0A Floating Point Unit POST Sequence 0B SC POST Sequence 0C Cacheable Instruction POST Sequence 0D Softint POST Sequence 0E CPU Cross Call POST Sequence 0F CMU-CH POST Sequence 10 PCI-CH POST Sequence 11 Master Device POST Sequence 12 DSCP POST Sequence 13 SC Check Before STICK Diag POST Sequence 14 STICK Stop POST Sequence 15 STICK Start POST Sequence 16 Error CPU Check POST Sequence 17 System Configuration POST Sequence 18 System Status Check POST Sequence 19 System Status Check After Sync POST Sequence 1A OpenBoot Start... POST Sequence Complete. ChassisSerialNumber BCF080207K Sun SPARC Enterprise M5000 Server, using Domain console Copyright 2010 Sun Microsystems, Inc. All rights reserved. Copyright 2010 Sun Microsystems, Inc. and Fujitsu Limited. All rights reserved. OpenBoot 4.24.14, 65536 MB memory installed, Serial #75515882. Ethernet address 0:14:4f:80:47:ea, Host ID: 848047ea. Rebooting with command: boot Boot device: rootmirror File and args: SunOS Release 5.10 Version Generic_142900-13 64-bit Copyright 1983-2010 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. NOTICE: zfs_parse_bootfs: error 48 Cannot mount root on rpool/47 fstype zfs panic[cpu0]/thread=180e000: vfs_mountroot: cannot mount root 0180b950 genunix:vfs_mountroot+358 (800, 200, 0, 18ef800, 1918000, 194dc00) %l0-3: 010c2400 010c22ec 018f5178 011f5400 %l4-7: 011f5400 01950400 0600 0200 0180ba10 genunix:main+9c (0, 180c000, 1892260, 1833358, 1839738, 1940800) %l0-3: 0180c000 0180c000 70002000 %l4-7: 0189c800 0180c000 0001 And the bootfs ID thing i read it from the following opensolaris link where one user was getting was the same error as mine. http://opensolaris.org/jive/thread.jspa?messageID=315743 Can you plz tell me some other way to get it rt ? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
