[zfs-discuss] ZFS bug - should I be worried about this?
I found this today: http://blog.lastinfirstout.net/2010/06/sunoracle-finally-announces-zfs-data.html?utm_source=feedburnerutm_medium=feedutm_campaign=Feed%3A+LastInFirstOut+%28Last+In%2C+First+Out%29utm_content=FriendFeed+Bot How can I be sure my Solaris 10 systems are fine? Is latest OpenSolaris (134) safe? Thx Gabriele. -- 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 bug - should I be worried about this?
Yes, I did read it. And what worries me is patches availability... -- 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 bug - should I be worried about this?
mmmI double checked some of the running systems. Most of them have the first patch (sparc-122640-05 and x86-122641-06), but not the second one (sparc-142900-09 and x86-142901-09)... ...I feel I'm right in the middle of the problem... How much am I risking?! These systems are all mirrored via zpool... Would this really make me safe without patching?? : set zfs:zfs_immediate_write_sz=10 set zfs:zvol_immediate_write_sz=10 Or a Log would be preferred? *sweat* These systems are all running for years nowand I considered them safe... Have I been at risk all this time?! -- 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 bug - should I be worried about this?
Yes...they're still running...but being aware that a power failure causing an unexpected poweroff may make the pool unreadable is a pain Yes. Patches should be available. Or adoption may be lowering a lot... -- 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 bug - should I be worried about this?
Oh well, thanks for this answer. It makes me feel much better! What are eventual risks? Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY http://www.sonicle.com -- Da: Victor Latushkin A: Gabriele Bulfon Cc: zfs-discuss@opensolaris.org Data: 28 giugno 2010 16.14.12 CEST Oggetto: Re: [zfs-discuss] ZFS bug - should I be worried about this? On 28.06.10 16:16, Gabriele Bulfon wrote: Yes...they're still running...but being aware that a power failure causing an unexpected poweroff may make the pool unreadable is a pain Pool integrity is not affected by this issue. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Daily snapshots as replacement for incremental backups
Hello, I have a situation where a zfs file server holding lots of graphic files cannot be backed up daily with a full backup. My idea was initially to run a full backup on Sunday through the lto library on more dedicated tapes, then have an incremental backup run on daily tapes. Brainstorming on this, led me to the idea that I could actually stop thinking about incremental backups (that may always lead me to unsafe backups anyway for some unlucky reason) and substitute the idea with daily snapshots. Actually, the full disaster ricovery is on the Sunday full backups (that can be safely taken away on Monday), while the daily solution would be just a safe place for daily errors by users (people who delete files by mistake, for example). This can be done simply running a snapshot per day during the night. My idea is to have cron to rotate snapshots during working days, so that I always have Mon,Tue,Wen,Thu,Fri,Sat snapshots, and have the cron shell delete the oldest (actually, if I have to run a Mon snapshot, I will delete the old Mon snapshots, this should run the cycle). My questions are: - is this a good and common solution? - is there any zfs performance degradation caused by creating and deleting snapshots on a daily basis, maybe fragmenting the file system? Thanx for any suggestion Gabriele. -- 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 on ZFS based storage?
Thanks for your suggestions :) Another thing comes to my mind (expecially after a past bad experience with a buggy storage non-zfs backend). Usually (correct me if I'm wrong) the storage will be having redundancy on its zfs volumes (be it mirror or raidz). Once the redundant volume is exposed as a single iScsi volume, the virtual solaris will create his own zfs filesystem on it (unaware of its redundant backend). One of the best practices I've read specifically tells that single resource pools are unsafe. In this case, the backend knows it's actually redundant, but the virtual os does not, and actually have just a single resource mounted as its zfs disk. Is this situation safe? Should I expose two iScsi volumes and let the virtual os again use a redundant zpool on them? This would obviously double again the disk requirements... Thanks again for any idea. Gabriele. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Disks configuration for a zfs based samba/cifs file server
Hi, I would love some suggestions for an implementation I'm going to deploy. I will have a machine with 4x1T disks, going to be a file server for both windows and osx clients through smb/cifs. I have read on zfs best practices articles that slicing is not suggested (unless you want to just create one slice for each disk to slightly lower each disk size, to be prepared for disks small differences in case of substitution of any of them). The best method I've read is to create 2 zpool mirrors of the entire disks, trying to cross controllers in each mirror, and having both mirrors into one zfs mount. This is clear to me. This is for the file server data. Question is...where should install the OS now?! Usually 10-20Gb is enough to install the entire distribution of Solaris, so I usually slice 2 disks, so to have a mirrored boot slice, then create the data zpool by joining the remaining mirrored slices of the boot disks with the entire remaining mirrored disk. Now I read this is not the best practice. In case I have another 2 disks slot, I may add another 2 smaller disks for the OS boot. But even in this case, minimum sizes for this smaller disks would lead me to a very big boot disk, almost wasted space. What should I actually do in these cases? Last question: in this deployment, my windows/osx users have no windows domain. Running samba and sharing to users is quick and easy. Would it be better to use native cifs sharing options of zfs? Would it work even in a non window-domain-controlled network? Thanks a lot, Gabriele. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS on ZFS based storage?
I'm trying to guess what is the best practice in this scenario: - let's say I have a zfs based storage (let's say nexenta) that has it zfs pools and volumes shared as iScsi raw devices - let's say I have another server running xvm or virtualbox connected to the storage - let's say one of the virtual guests is OpenSolaris My question is: - is it correct to mount the iScsi device as base disks for the VM and then create zpools/volumes in it, considering that behind it there is already another zfs? - what alternatives do I have? - in case it's correct to have the VM zfs over the storage zfs, where should I manage snapshots? on the VM or on the storage? Thanks for any idea Gabriele. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] corruption of ZFS on iScsi storage
Hello, I'd like to check for any guidance about using zfs on iscsi storage appliances. Recently I had an unlucky situation with an unlucky storage machine freezing. Once the storage was up again (rebooted) all other iscsi clients were happy, while one of the iscsi clients (a sun solaris sparc, running Oracle) did not mount the volume marking it as corrupted. I had no way to get back my zfs data: had to destroy and recreate from backups. So I have some questions regarding this nice story: - I remember sysadmins being able to almost always recover data on corrupted ufs filesystems by magic of superblocks. Is there something similar on zfs? Is there really no way to access data of a corrupted zfs filesystem? - In this case, the storage appliance is a legacy system based on linux, so raids/mirrors are managed at the storage side its own way. Being an iscsi target, this volume was mounted as a single iscsi disk from the solaris host, and prepared as a zfs pool consisting of this single iscsi target. ZFS best practices, tell me that to be safe in case of corruption, pools should always be mirrors or raidz on 2 or more disks. In this case, I considered all safe, because the mirror and raid was managed by the storage machine. But from the solaris host point of view, the pool was just one! And maybe this has been the point of failure. What is the correct way to go in this case? - Finally, looking forward to run new storage appliances using OpenSolaris and its ZFS+iscsitadm and/or comstar, I feel a bit confused by the possibility of having a double zfs situation: in this case, I would have the storage zfs filesystem divided into zfs volumes, accessed via iscsi by a possible solaris host that creates his own zfs pool on it (...is it too redundant??) and again I would fall in the same previous case (host zfs pool connected to one only iscsi resource). Any guidance would be really appreciated :) Thanks a lot Gabriele. -- 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] corruption of ZFS on iScsi storage
Well, I actually don't know what implementation is inside this legacy machine. This machine is an AMI StoreTrends ITX, but maybe it has been built around IET, don't know. Well, maybe I should disable write-back on every zfs host connecting on iscsi? How do I check this? Thx Gabriele. -- 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 Problems under vmware
Hello, I'm having the same exact situation on one VM, and not on another VM on the same infrastructure. The only difference is that on the failing VM I initially created the pool with a name and then changed the mountpoint to another name. Did you found a solution to the issue? Should I consider to get back to UFS on this infrastructure? Thanx a lot Gabriele. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS raidz1 replacing failing disk
I'm having a serious problem with a customer running a T2000 with ZFS configured as raidz1 with 4 disks, no spare. The machine is mostly a cyrus imap server and web application server to run the ajax app to email. Yesterday we had a heavy slow down. Tomcat runs smoothly, but the imap access is very slow, also through a direct imap client runnining on LAN PCs. We figured out that the 4th disk was signaling hardware errors on /var/adm/messages, but no error could be seen on zpool. A technician went there to substitute the disk. My idea was to add the disk to the zpool, issue a replace command so to remove the failing disk. The technician by mistake did something different: he created a spare device containing both the failing disk and the new one. So at the moment I have the 3 original disks, and one spare containing the new one and the falining one. Today I turned offline the failing disk, so the spare device is using the new disk. Then I turned off the T2000, removed physically the failing disk, and turned on everything. Now I have this output: -bash-3.00# zpool status pool: dskmail state: DEGRADED status: One or more devices has been taken offline by the adminstrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using 'zpool online' or replace the device with 'zpool replace'. scrub: resilver completed with 0 errors on Wed Apr 16 08:38:54 2008 config: NAME STATE READ WRITE CKSUM dskmail DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 c3t9d0s0 ONLINE 0 0 0 c3t10d0s0ONLINE 0 0 0 c3t12d0s0ONLINE 0 0 0 spareDEGRADED 0 0 0 c3t13d0s0 OFFLINE 0 0 0 c3t14d0s0 ONLINE 0 0 0 spares c3t14d0s0 INUSE currently in use errors: No known data errors As you can see, the t13 disk is offline and physically removed. The machine is still very slow. I want to remove the t13 disk from the zpool, but I can't. My question is: - How do I put the t14 disk as it should be? (added as no spare) - Can I simply remove the spare device while the machine is running without any risk? - What will happen if I then add the t14 device to the 3 disks? Will it start a new sync? What I think is that the t14 should already contain raid data, as sync has already terminated, while inside the spare. So, adding it as no spare should not reissue the sync process again, if not for the few data in between. Am I wrong? Thanx for any help, really. Gabriele Bulfon This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Securing a risky situation with zfs
Hi, we're having a bad situation with a SAN iScsi solution in a production environment of a customer: the storage hardware may panic its kernel because of its software fault, with the risk of loosing data. We want to give the SAN manufacturer a last chance of correcting their solution: we're going to move data from the SAN to new fresh scsi-attached disks, for the time needed for them to find the bugs. Once they've certified us the solution, we will move back the data onto the SAN. Here comes the issue: we can't risk our customer's data to be again on a possibly faulty SAN, so we were thinking about reusing the scsi-attached disks as part of the zfs pool of the SAN partitions. The basic idea was to have a zfs mirror of each iscsi disk on scsi-attached disks, so that in case of another panic of the SAN, everything should still work on the scsi-attached disks. My questions are: - is this a good idea? - should I use zfs mirrors or normal solaris mirrors? - is mirroring the best performance, or should I use zfs raid-z? - is there any other possibility I don't see? Last but not least (I know the question is not pertinent, but maybe you can help): - The SAN includes 2 Sun-Solaris-10 machines, and 3 windows machinesis there any similar solution on the win machines? Thanx for any help Gabriele Bulfon. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
