Re: [zfs-discuss] more ZFS recovery
Hello max, Sunday, August 17, 2008, 1:02:05 PM, you wrote: mbc> A Darren Dunham wrote: >> >> If the most recent uberblock appears valid, but doesn't have useful >> data, I don't think there's any way currently to see what the tree of an >> older uberblock looks like. It would be nice to see if that data >> appears valid and try to create a view that would be >> readable/recoverable. >> >> mbc> I have a method to examine uberblocks on disk. Using this, along with mbc> my modified mbc> mdb and zdb, I have been able to recover a previously removed file. mbc> I'll post mbc> details in a blog if there is interest. Of course, pleas do so. -- Best regards, Robert Milkowskimailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] cannot delete file when fs 100% full
Hello Paul, Thursday, August 14, 2008, 9:25:45 PM, you wrote: PR> This problem is becoming a real pain to us again and I was wondering PR> if there has been in the past few month any known fix or workaround. PR> I normally create zfs fs's like this: PR>zfs create -o quota=131G -o reserv=131G -o recsize=8K zpool1/newvol PR> and then just nfs export through /etc/dfs/dfstab. We deal with lots PR> of small image files in our MRI data which is the reason for small PR> recsize. If you are creating lots of small files and you are not worried about accessing only small parts of them with a smaller block, then it doesn't really make sense to reduce record size. With standard 128K recsize if you create a small file, lets say 8K in size, the block size used by zfs will be actually 8K. Unless you are doing this to work-around space maps issue. -- Best regards, Robert Milkowskimailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] C code for reading ZFS ACL
Paul B. Henson wrote: > Sweet. Might I request an acl evaluation function? Which basically, given a > user and a requested permission, returns either true (user has permission), > false (user doesn't have permission), or error condition. Similar to the > POSIX access() call, but for ACLs. If I had that I wouldn't need to be > mucking around with the ACL directly at all :), as that's basically what > I'm implementing... You need to understand though that access(2) and any equivalent function that evaluates an ACL is NOT authoritative. The only way to get an authoratative answer is to actually try the operation. In privileged programs you must be careful that you do not introduce "Time Of Check To Time Of Use" security vulnerabilities when using functions like access(2). Only the kernel should make the access control decision and use of functions like access(2) should generally only be used to assist in providing a more informative error message. The reason for this is is that it is not just the evaluation of the ACL/permission as that user that determines the final result. Other things can impact it as well - for example the Trusted Extensions mandatory access label (ie a zone) and in the future the FMAC[1] security context. As long as you take that into account a function to evaluate access control can be used safely. [1] http://opensolaris.org/os/project/fmac/ -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] shrinking a zpool - roadmap
Hi, I am searching for a roadmap for shrinking a pool. Is there some project, where can I find informations, when will it be implemented in Solars10 Thanks Regards Bernhard -- Bernhard Holzer Sun Microsystems Ges.m.b.H. Wienerbergstraße 3/7 A-1100 Vienna, Austria Phone x60983/+43 1 60563 11983 Mobile +43 664 60563 11983 Fax +43 1 60563 11920 Email [EMAIL PROTECTED] Handelsgericht Wien, Firmenbuch-Nr. FN 186250 y ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Odp: Kernel panic at zpool import
> Try to change uberblock > http://www.opensolaris.org/jive/thread.jspa?messageID= > 217097 Looks like you are the originator of that thread. In the last message you promised to post some details on how you've recovered, but it was not done. Can you please post some details? How did you figure out offsets for vdev_uberblock_compare? Thank you! 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] shrinking a zpool - roadmap
Long story short, There isn't a project, there are no plans to start a project, and don't expect to see it in Solaris10 in this lifetime without some serious pushback from large Sun customers. Even then, it's unlikely to happen anytime soon due to the technical complications of doing so reliably. --Tim On Mon, Aug 18, 2008 at 6:06 AM, Bernhard Holzer <[EMAIL PROTECTED]>wrote: > Hi, > > I am searching for a roadmap for shrinking a pool. Is there some > project, where can I find informations, when will it be implemented in > Solars10 > > Thanks > Regards > Bernhard > > -- > Bernhard Holzer > Sun Microsystems Ges.m.b.H. > Wienerbergstraße 3/7 > A-1100 Vienna, Austria > Phone x60983/+43 1 60563 11983 > Mobile +43 664 60563 11983 > Fax +43 1 60563 11920 > Email [EMAIL PROTECTED] > Handelsgericht Wien, Firmenbuch-Nr. FN 186250 y > > > ___ > 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] cannot delete file when fs 100% full
I read that that should be case but did not see such in practice. I created one volume without the recsize setting and one with. Than copied the same data to both (lots of small files). The 'du' report on the one without the recsize was significantly bigger than the one where I made it and in fact filled up before the other volume. On Mon, 18 Aug 2008, Robert Milkowski wrote: > Hello Paul, > > Thursday, August 14, 2008, 9:25:45 PM, you wrote: > > PR> This problem is becoming a real pain to us again and I was wondering > PR> if there has been in the past few month any known fix or workaround. > > PR> I normally create zfs fs's like this: > > PR>zfs create -o quota=131G -o reserv=131G -o recsize=8K zpool1/newvol > > PR> and then just nfs export through /etc/dfs/dfstab. We deal with lots > PR> of small image files in our MRI data which is the reason for small > PR> recsize. > > If you are creating lots of small files and you are not worried about > accessing only small parts of them with a smaller block, then it > doesn't really make sense to reduce record size. With standard 128K > recsize if you create a small file, lets say 8K in size, the block > size used by zfs will be actually 8K. > > Unless you are doing this to work-around space maps issue. > > > -- --- Paul Rainesemail: raines at nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129USA ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Zfs and mpxio - device name changed
Hi all, I have defined a zfs pool on a Solaris 10 : [EMAIL PROTECTED]:/kernel/drv> zpool list NAMESIZEUSED AVAILCAP HEALTH ALTROOT nsrcatalog 125G 72.7G 52.4G58% ONLINE - [EMAIL PROTECTED]:/kernel/drv> zpool status nsrcatalog pool: nsrcatalog state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM nsrcatalog ONLINE 0 0 0 mirror ONLINE 0 0 0 c7t500507630708433Bd0 ONLINE 0 0 0 c6t5005076307034352d0 ONLINE 0 0 0 mirror ONLINE 0 0 0 c7t500507630708433Bd1 ONLINE 0 0 0 c6t5005076307034352d1 ONLINE 0 0 0 mirror ONLINE 0 0 0 c7t500507630708433Bd2 ONLINE 0 0 0 c6t5005076307034352d2 ONLINE 0 0 0 mirror ONLINE 0 0 0 c7t500507630708433Bd3 ONLINE 0 0 0 c6t5005076307034352d3 ONLINE 0 0 0 mirror ONLINE 0 0 0 c7t500507630708433Bd4 ONLINE 0 0 0 c6t5005076307034352d4 ONLINE 0 0 0 mirror ONLINE 0 0 0 c7t500507630708433Bd5 ONLINE 0 0 0 c6t5005076307034352d5 ONLINE 0 0 0 mirror ONLINE 0 0 0 c7t500507630708433Bd6 ONLINE 0 0 0 c6t5005076307034352d6 ONLINE 0 0 0 errors: No known data errors I would now like to use mpxio - multipathing driver. So, i will change the file /kernel/drv/fp.conf and set the parameter mpxio-disable="no"; But, I thing Solaris will change after a reboot the device name !!. What will be the status of my zpool after the reboot. Do I have to redefine it ? How can I preserve data on it ? Thanks a lot for your help. Kind regards. Pierre. - Visit our website! http://www.nbb.be "DISCLAIMER: The content of this e-mail message should not be construed as binding on the part of the National Bank of Belgium (NBB) unless otherwise and previously stated. The opinions expressed in this message are solely those of the author and do not necessarily reflect NBB viewpoints, particularly when the content of this message, or part thereof, is private by nature or does not fall within the professional scope of its author."___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] C code for reading ZFS ACL
Ian Collins wrote: > Mark Shellenbaum wrote: >> Paul B. Henson wrote: >>> Are the libsec undocumented interfaces likely to remain the same when the >>> acl_t structure changes? They will still require adding the prototypes to >>> my code so the compiler knows what to make of them, but less chance of >>> breakage is good. >>> >>> >> I can't guarantee they will remain in the future. Thats why they aren't >> documented. >> >> It may be that with appropriate iterators and other interfaces they will >> no longer be needed. >> >> > I'm working on a similar problem to Paul (sorry I didn't get back to you > Paul - shifting priorities!), writing a PHP extension for ACLs, and I've > fallen into the trap of using acl_info. Is this work you mention > happening in the open, or in side of Sun? If it's the former, how can > we get involved? > > Ian Currently we are just doing some preliminary discussions internal to Sun? Were you looking to help out and provide some code? We could probably include you in the discussions if you are interested. -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zfs and mpxio - device name changed
On Mon, Aug 18, 2008 at 04:43:02PM +0200, Dony Pierre wrote: > >I have defined a zfs pool on a Solaris 10 : > >I would now like to use mpxio - multipathing driver. So, i will change >the file /kernel/drv/fp.conf and set the parameter mpxio-disable="no"; > >But, I thing Solaris will change after a reboot the device name !!. >What will be the status of my zpool after the reboot. Do I have to >redefine it ? > >How can I preserve data on it ? We've done the same thing with ZFS on Iscsi devices. Once we set up the second path, we exported the pool. Then, we enabled mpxio and imported the pool again. `zpool import' will show the new device names, but you only need to specify the pool name. It worked perfectly. -- -Gary Mills--Unix Support--U of M Academic Computing and Networking- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Poor read/write performance when using ZFS iSCSI target
initiator_host:~ # dd if=/dev/zero bs=1k of=/dev/dsk/c5t0d0 count=100 So this is going at 3000 x 1K writes per second or 330usec per write. The iscsi target is probably doing a over the wire operation for each request. So it looks fine at first glance. -r Cody Campbell writes: > Greetings, > > I want to take advantage of the iSCSI target support in the latest > release (svn_91) of OpenSolaris, and I'm running into some performance > problems when reading/writing from/to my target. I'm including as much > detail as I can so bear with me here... > > I've built an x86 OpenSolaris server (Intel Xeon running NV_91) with a > zpool of 15 750GB SATA disks, of which I've created and exported a ZFS > Volume with the shareiscsi=on property set to generate an iSCSI > target. > > My problem is, when I connect to this target from any initiator > (tested with both Linux 2.6 and OpenSolaris NV_91 SPARC and x86), the > read/write speed is dreadful (~ 3 megabytes / second!). When I test > read/write performance locally with the backing pool, I have excellent > speeds. The same can be said when I use services such as NFS and FTP > to move files between other hosts on the network and the volume I am > exporting as a Target. When doing this I have achieved the > near-Gigabit speeds I expect, which has me thinking this isn't a > network problem of some sort (I've already disabled the Neagle > algorithm if you're wondering). It's not until I add the iSCSI target > to the stack that the speeds go south, so I am concerned that I may be > missing something in configuration of the target. > > Below are some details pertaining to my configuration. > > OpenSolaris iSCSI Target Host: > > target_host:~ # zpool status pool0 > pool: pool0 > state: ONLINE > scrub: none requested > config: > > NAMESTATE READ WRITE CKSUM > pool0 ONLINE 0 0 0 > raidz1ONLINE 0 0 0 > c0t0d0 ONLINE 0 0 0 > c0t1d0 ONLINE 0 0 0 > c0t2d0 ONLINE 0 0 0 > c0t3d0 ONLINE 0 0 0 > c0t4d0 ONLINE 0 0 0 > c0t5d0 ONLINE 0 0 0 > c0t6d0 ONLINE 0 0 0 > raidz1ONLINE 0 0 0 > c0t7d0 ONLINE 0 0 0 > c1t0d0 ONLINE 0 0 0 > c1t1d0 ONLINE 0 0 0 > c1t2d0 ONLINE 0 0 0 > c1t3d0 ONLINE 0 0 0 > c1t4d0 ONLINE 0 0 0 > c1t5d0 ONLINE 0 0 0 > spares > c1t6d0AVAIL > > errors: No known data errors > > target_host:~ # zfs get all pool0/vol0 > NAMEPROPERTY VALUE SOURCE > pool0/vol0 type volume - > pool0/vol0 creation Wed Jul 2 18:16 2008 - > pool0/vol0 used 5T - > pool0/vol0 available7.92T - > pool0/vol0 referenced 34.2G - > pool0/vol0 compressratio1.00x - > pool0/vol0 reservation none default > pool0/vol0 volsize 5T - > pool0/vol0 volblocksize 8K - > pool0/vol0 checksum on default > pool0/vol0 compression offdefault > pool0/vol0 readonly offdefault > pool0/vol0 shareiscsi on local > pool0/vol0 copies 1 default > pool0/vol0 refreservation 5T local > > > target_host:~ # iscsitadm list target -v pool0/vol0 > > Target: pool0/vol0 > iSCSI Name: iqn.1986-03.com.sun:02:fb1c7071-8f35-eb03-9efb-b950d5bdd1ab > Alias: pool0/vol0 > Connections: 1 > Initiator: > iSCSI Name: iqn.1986-03.com.sun:01:0003ba681e7f.486c0829 > Alias: unknown > ACL list: > TPGT list: > TPGT: 1 > LUN information: > LUN: 0 > GUID: 01304865b1b42a00486c29d2 > VID: SUN > PID: SOLARIS > Type: disk > Size: 5.0T > Backing store: /dev/zvol/rdsk/pool0/vol0 > Status: online > > > OpenSolaris iSCSI Initiator Host: > > > initiator_host:~ # iscsiadm list target -vS > iqn.1986-03.com.sun:02:fb1c7071-8f35-eb03-9efb-b950d5bdd1ab > Target: iqn.1986-03.com.sun:02:fb1c7071-8f35-eb03-9efb-b950d5bdd1ab > Alias: pool0/vol0 > TPGT: 1 > ISID: 402a > Connections: 1 > CID: 0 > IP address (Local): 192.168.4.2:63960 > IP address (Peer): 192.168
Re: [zfs-discuss] Why RAID 5 stops working in 2009
Kyle McDonald writes: > Ross wrote: > > Just re-read that and it's badly phrased. What I meant to say is that a > > raid-z / raid-5 array based on 500GB drives seems to have around a 1 in 10 > > chance of loosing some data during a full rebuild. > > > > > > > Actually, I think it's been explained already why this is actually one > area where RAID-Z will really start to show some of the was it's > different than it's RAID-5 ancestors. For one, A RAID-5 controller has > no idea of the filesystem, and there for has to rebuild every bit on the > disk, whether it's used or not, and if it cant' it will declare the > whole array unusable. RAID-Z on the other hand since it is integrated > with the filesystem, only needs to rebuild the *used* data, and won't > care if unused parts of the disks can't be rebuilt. > > Second, a factor that the author of that article leaves out is that > decent RAID-5, and RAID-Z can do 'scrubs' of the data at regular > intervals, and this will many times catch and deal with these read > problems well before they have a chance to take all your data with them. > The types of errors the author writes about many times are caused by how > accurately the block was written and not a defect of the media, so many > times they can be fixed by just rewriting the data to the same block. On > ZFS this will almost never happen, because of COW it will always choose > a new block to write to. I don't think many (if any) RAID-5 > implementaions can change the location of data on a drive. > Moreover, ZFS stores redundant copies of metadata so even if a full raid-z stripe goes south, we can still rebuild most of pool data. It seems that at worst, such double failures would lead to a handful of un-recovered files. -r > -Kyle > > > 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] OpenSolaris installer can't be run, if target ZFS pool exists.
Hi ZFS team, I am currently working on fixes for couple of bugs in OpenSolaris Caiman installer and since they are related to the ZFS, I would like to kindly ask you, if you could please help me to understand, if the issues encountered and mentioned below are known (somebody works on them or if they are already fixed), or if some workarounds might be used. Also, please let us know if there is possibility that other approach (like other/new API, command, subcommand) might be used in order to solve the problem. Any help/suggestions/comments are much appreciated. Thank you very much, Jan Let me describe the main problem we are trying to address by the fix which is tracked by following bug: 1771 Install will fail if rpool ZFS pool already exists When OpenSolaris starts process of installation, it creates ZFS root pool "rpool" on the target, which is then populated with appropriate ZFS datasets and ZFS volumes (used for swap and dump) - then Solaris is installed there. If installer exits either due to some kind of failure or user intervention, we would like to make sure, it can be restarted again. Because of this, we need to destroy all allocated resources, which in ZFS case means we need to release "rpool", so that installer could use it again. The problem is that we don't know, if "rpool" was just created by the installer or imported by user (for example other Solaris instance might exist on other disk). If latter is the case, we don't want to destroy the pool. We were trying to address this problem in following ways, but none of them worked for us due to the issues encountered: [1] Installing into "temporary" pool Installer created "rpool_tmp" for installation and when installation successfully finished, it was "renamed" to "rpool". If installer failed during installation, we knew that we could safely remove "rpool_tmp", since this was only temporary pool and thus couldn't contain valid Solaris instance. We were "renaming" the pool in following way: # zpool create -f rpool_tmp [...installation...] # pool_id=`zpool list -H -o guid rpol_tmp` # zpool export -f rpool_tmp # zpool import -f $pool_id rpool However, we encountered problem that sometimes root "/rpool" dataset was not mounted due to some reason and we failed to access it. Please see more details in bug report 1350 Install without menu.lst [2] Exporting "rpool" if present on the system == When installer started, it checked if "rpool" is present and in that case it exported it. # zpool export -f rpool The problem is that this operation made "rpool" unbootable: 1365 zfs import/export will modify the boot up information of ZFS So if user had some Solaris instance on that pool, it was not able to boot it anymore (without importing the pool). ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] C code for reading ZFS ACL
Mark Shellenbaum wrote: > Ian Collins wrote: >> Mark Shellenbaum wrote: >>> Paul B. Henson wrote: Are the libsec undocumented interfaces likely to remain the same when the acl_t structure changes? They will still require adding the prototypes to my code so the compiler knows what to make of them, but less chance of breakage is good. >>> I can't guarantee they will remain in the future. Thats why they >>> aren't documented. >>> >>> It may be that with appropriate iterators and other interfaces they >>> will no longer be needed. >>> >>> >> I'm working on a similar problem to Paul (sorry I didn't get back to you >> Paul - shifting priorities!), writing a PHP extension for ACLs, and I've >> fallen into the trap of using acl_info. Is this work you mention >> happening in the open, or in side of Sun? If it's the former, how can >> we get involved? >> >> Ian > > Currently we are just doing some preliminary discussions internal to > Sun? Were you looking to help out and provide some code? We could > probably include you in the discussions if you are interested. > I've been doing quite a bit of work on the user side of the fence recently, so yes I would be interesting in contributing. Ian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Kernel panic at zpool import
>Suppose that ZFS detects an error in the first > case. It can't tell > the storage array "something's wrong, please > fix it" (since the > storage array doesn't provide for this with > checksums and intelligent > recovery), so all it can do is tell the user > "this file is corrupt, > recover it from backups". Just to remind you. System was working fine with no sign of any failures. Data got corrupted at export operation. If storage was somehow misbehaving I would expect ZFS to complain about it on any operation which did not finish succesfully. I had NONE issues on the system with quite extensive read/write activity. System panicked on export and messed everything such that pools could not be imported. At what moment ZFS whould do better if I had even raid1 configuration? I assume that this mess would be written on both disks and how this would help me in recovering. I do understand that having more disks would be better in case of failure of one or several of them. But only if it's related to disks. I'm almost sure disks were fine during failure. Is there anything you can improve apart from ZFS to cope with such issues? 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] Kernel panic at zpool import
> Ask your hardware vendor. The hardware corrupted your > data, not ZFS. Right, that's all because of these storage vendors. All problems come from them! Never from ZFS :-) I have similar answer from them: ask Sun, ZFS is buggy. Our storage is always fine. That is really ridiculous! People pay huge money on storage and its support plus same for hardware and OS to get at the end both parties blaming each other with no intention to look deeper. 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 commands hanging in B95
Ian Collins wrote: > I have a pretty standard ZFS boot AMD64 desktop. A the moment, most ZFS > related commands are hanging (can't be killed) . Running 'truss share' > the last few lines I see are: > Can you provide a kernel thread list report? You can use mdb -k to get that. Once in mdb type ::threadlist -v -Mark ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Kernel panic at zpool import
Borys Saulyak wrote: >> Suppose that ZFS detects an error in the first >> case. It can't tell >> the storage array "something's wrong, please >> fix it" (since the >> storage array doesn't provide for this with >> checksums and intelligent >> recovery), so all it can do is tell the user >> "this file is corrupt, >> recover it from backups". >> > Just to remind you. System was working fine with no sign of any failures. > Data got corrupted at export operation. If storage was somehow misbehaving I > would expect ZFS to complain about it on any operation which did not finish > succesfully. From what I can predict, and *nobody* has provided any panic messages to confirm, ZFS likely had difficulty writing. For Solaris 10u5 and previous updates, ZFS will panic when writes cannot be completed successfully. This will be clearly logged. For later releases, the policy set in the pool's failmode property will be followed. Or, to say this another way, the only failmode property in Solaris 10u5 or NV builds prior to build 77 (October 2007) is "panic." For later releases, the default failmode is "wait," but you can change it. > I had NONE issues on the system with quite extensive read/write activity. > System panicked on export and messed everything such that pools could not be > imported. At what moment ZFS whould do better if I had even raid1 > configuration? I assume that this mess would be written on both disks and how > this would help me in recovering. I do understand that having more disks > would be better in case of failure of one or several of them. But only if > it's related to disks. I'm almost sure disks were fine during failure. Is > there anything you can improve apart from ZFS to cope with such issues? > > I think that nobody will be able to pinpoint the cause until someone looks at the messages and fma logs. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zfs and mpxio - device name changed
Dony Pierre wrote: > > Hi all, > > I have defined a zfs pool on a Solaris 10 : > > [EMAIL PROTECTED]:/kernel/drv> zpool list > NAMESIZEUSED AVAILCAP HEALTH ALTROOT > nsrcatalog 125G 72.7G 52.4G58% ONLINE - > > [EMAIL PROTECTED]:/kernel/drv> zpool status nsrcatalog > pool: nsrcatalog > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > nsrcatalog ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd0 ONLINE 0 0 0 > c6t5005076307034352d0 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd1 ONLINE 0 0 0 > c6t5005076307034352d1 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd2 ONLINE 0 0 0 > c6t5005076307034352d2 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd3 ONLINE 0 0 0 > c6t5005076307034352d3 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd4 ONLINE 0 0 0 > c6t5005076307034352d4 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd5 ONLINE 0 0 0 > c6t5005076307034352d5 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd6 ONLINE 0 0 0 > c6t5005076307034352d6 ONLINE 0 0 0 > > errors: No known data errors > > I would now like to use mpxio - multipathing driver. So, i will change > the file /kernel/drv/fp.conf and set the parameter mpxio-disable="no"; > > But, I thing Solaris will change after a reboot the device name !!. What > will be the status of my zpool after the reboot. Do I have to redefine it ? > > How can I preserve data on it ? Yes, the cXtYdZ paths will change. You don't even need to export and import the pool, ZFS looks at the devid (device id) of each disk in your pool in preference to a device path - if the devid doesn't change (and it shouldn't!), then there's no issue at all. I strongly advise you to use the stmsboot(1m) command to handle the enabling of MPxIO. Otherwise your system might not boot - there are a few niggly little things that stmsboot(1m) does for you which you might not do by yourself. If you'd like more information on devids, please have a look at my presentation on the concept: http://www.jmcp.homeunix.com/~jmcp/WhatIsAGuid.pdf James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS commands hanging in B95
Mark Shellenbaum wrote: > Ian Collins wrote: >> I have a pretty standard ZFS boot AMD64 desktop. A the moment, most ZFS >> related commands are hanging (can't be killed) . Running 'truss share' >> the last few lines I see are: >> > > Can you provide a kernel thread list report? You can use mdb -k to > get that. Once in mdb type ::threadlist -v > Here you go: > ::threadlist -v ADDR PROC LWP CLS PRIWCHAN fbc29420 fbc287b0 fbc2b010 0 960 PC: _resume_from_idle+0xf1CMD: sched stack pointer for thread fbc29420: fbc48d60 [ fbc48d60 _resume_from_idle+0xf1() ] swtch+0x17f() sched+0x423() main+0x419() _locore_start+0x92() ff0007a05c80 fbc287b00 0 -10 PC: _resume_from_idle+0xf1THREAD: idle() stack pointer for thread ff0007a05c80: ff0007a05c00 [ ff0007a05c00 _resume_from_idle+0xf1() ] cpu_idle+0xe9() idle+0x10e() thread_start+8() ff0007a0bc80 fbc287b00 0 60 fbcaa8b0 PC: _resume_from_idle+0xf1THREAD: thread_reaper() stack pointer for thread ff0007a0bc80: ff0007a0bb90 [ ff0007a0bb90 _resume_from_idle+0xf1() ] swtch+0x17f() cv_wait+0x61() thread_reaper+0xb7() thread_start+8() ff0007a11c80 fbc287b00 0 60 ff01cce37e90 PC: _resume_from_idle+0xf1TASKQ: kmem_move_taskq stack pointer for thread ff0007a11c80: ff0007a11b60 [ ff0007a11b60 _resume_from_idle+0xf1() ] swtch+0x17f() cv_wait+0x61() taskq_thread+0x11e() thread_start+8() ff0007a17c80 fbc287b00 0 60 ff01cce37db8 PC: _resume_from_idle+0xf1TASKQ: kmem_taskq stack pointer for thread ff0007a17c80: ff0007a17b60 [ ff0007a17b60 _resume_from_idle+0xf1() ] swtch+0x17f() cv_wait+0x61() taskq_thread+0x11e() thread_start+8() ff0007a1dc80 fbc287b00 0 60 ff01cce37ce0 PC: _resume_from_idle+0xf1TASKQ: pseudo_nexus_enum_tq stack pointer for thread ff0007a1dc80: ff0007a1db60 [ ff0007a1db60 _resume_from_idle+0xf1() ] swtch+0x17f() cv_wait+0x61() taskq_thread+0x11e() thread_start+8() ff0007a23c80 fbc287b00 0 60 ff01cce37c08 PC: _resume_from_idle+0xf1TASKQ: scsi_vhci_nexus_enum_tq stack pointer for thread ff0007a23c80: ff0007a23b60 [ ff0007a23b60 _resume_from_idle+0xf1() ] swtch+0x17f() cv_wait+0x61() Ian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Moving a ZFS root to another target
* andrew <[EMAIL PROTECTED]> [2008-08-16 00:38]: > Hmm... Just tried the same thing on SXCE build 95 and it works fine. > Strange. Anyone know what's up with OpenSolaris (the distro)? I'm > using the ISO of OpenSolaris 208.11 snv_93 image-updated to build 95 > if that makes a difference. I've not tried this on 2008.05 . For a while, the boot-archive on 2008.nn systems included a copy of zpool.cache. Recent versions do not make this mistake. Delete and regenerate your boot archive, and you should be able to make the transfer. See http://mail.opensolaris.org/pipermail/indiana-discuss/2008-August/008341.html and following. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zfs and mpxio - device name changed
James, Thanks a lot for your answer and for your presentation. I will read it before making the activation of mpxio. Thanks ! Kind regards. Pierre. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: maandag 18 augustus 2008 22:49 To: Dony Pierre Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Zfs and mpxio - device name changed Dony Pierre wrote: > > Hi all, > > I have defined a zfs pool on a Solaris 10 : > > [EMAIL PROTECTED]:/kernel/drv> zpool list > NAMESIZEUSED AVAILCAP HEALTH ALTROOT > nsrcatalog 125G 72.7G 52.4G58% ONLINE - > > [EMAIL PROTECTED]:/kernel/drv> zpool status nsrcatalog > pool: nsrcatalog > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > nsrcatalog ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd0 ONLINE 0 0 0 > c6t5005076307034352d0 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd1 ONLINE 0 0 0 > c6t5005076307034352d1 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd2 ONLINE 0 0 0 > c6t5005076307034352d2 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd3 ONLINE 0 0 0 > c6t5005076307034352d3 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd4 ONLINE 0 0 0 > c6t5005076307034352d4 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd5 ONLINE 0 0 0 > c6t5005076307034352d5 ONLINE 0 0 0 > mirror ONLINE 0 0 0 > c7t500507630708433Bd6 ONLINE 0 0 0 > c6t5005076307034352d6 ONLINE 0 0 0 > > errors: No known data errors > > I would now like to use mpxio - multipathing driver. So, i will change > the file /kernel/drv/fp.conf and set the parameter mpxio-disable="no"; > > But, I thing Solaris will change after a reboot the device name !!. What > will be the status of my zpool after the reboot. Do I have to redefine it ? > > How can I preserve data on it ? Yes, the cXtYdZ paths will change. You don't even need to export and import the pool, ZFS looks at the devid (device id) of each disk in your pool in preference to a device path - if the devid doesn't change (and it shouldn't!), then there's no issue at all. I strongly advise you to use the stmsboot(1m) command to handle the enabling of MPxIO. Otherwise your system might not boot - there are a few niggly little things that stmsboot(1m) does for you which you might not do by yourself. If you'd like more information on devids, please have a look at my presentation on the concept: http://www.jmcp.homeunix.com/~jmcp/WhatIsAGuid.pdf James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog - Visit our website! http://www.nbb.be "DISCLAIMER: The content of this e-mail message should not be construed as binding on the part of the National Bank of Belgium (NBB) unless otherwise and previously stated. The opinions expressed in this message are solely those of the author and do not necessarily reflect NBB viewpoints, particularly when the content of this message, or part thereof, is private by nature or does not fall within the professional scope of its author." ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
