[zfs-discuss] ZFS vs FAT
Can u site the differences b/w ZFS and FAT filesystems?? 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 vs FAT
Rahul wrote: Can u site the differences b/w ZFS and FAT filesystems?? You are joking, aren't you? Have you read any of the ZFS documentation? Ian ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] are these errors dangerous
Hi, First of all, I really should warn you that I'm very new to Solaris, I'll happily share my thoughts but be aware that there's not a lot of experience backing them up. From what you've said, and the logs you've posted I suspect you're hitting recoverable read errors. ZFS wouldn't flag these as no corrupt data has been encountered, but I suspect the device driver is logging them anyway. The log you posted all appears to refer to one disk (sd0), my guess would be that you have some hardware faults on that device and if it were me I'd probably be replacing it before it actually fails. I'd check your logs before replacing that disk though, you need to see if it's just that one disk, or if others are affected. Provided you have a redundant ZFS pool, it may be worth offlining that disk, unconfiguring it with cfgadm, and then pulling the drive to see if that does cure the warnings you're getting in the logs. Whatever you do, please keep me posted. Your post has already made me realise it would be a good idea to have a script watching log file sizes to catch problems like this early. Ross 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 vs FAT
On Sun, Aug 3, 2008 at 9:31 AM, Rahul [EMAIL PROTECTED] wrote: Can u site the differences b/w ZFS and FAT filesystems?? Assuming you are serious, the technical bits can be found here: http://en.wikipedia.org/wiki/Comparison_of_file_systems But there is a bigger, fundamental difference between ZFS and all other file systems. Firstly, ZFS does away with traditional disk partitioning and space allocation principles. Many other volume managers claims to use storage pools in some form or another, but ZFS truly realizes this. To this effect, ZFS integrates volume management features to the POSIX layer. Basically, when a read from an application fails, the kernel is aware of the underlying bits which might save the day. In short, in stead of panic-ing because data is corrupted, it can possibly re-try the operation from a different disk, or even from a second copy on the same disk, etc. What is more, it will FIX the problem there and then, in the background. Example: Mirrored disks. One side of the mirror somehow fails the checksum on the data. ZFS reads from the other mirror, and returns good data to the application. But it goes further in that it fixes the bad data on the otehr mirror copy. Secondly, ZFS incorporates an amazing set of features: Online snapshots, encryption, reservations, quotas, compression, turning on and off these and several other features ONLINE. Third, ZFS administration is easy. No need to modify files to set mountpoins, share file systems, etc. The ZFS utilities will even turn on the required services for you when you share a file system via SMB or NFS. Lastly, ZFS's big claim to fame: Never get a corrupted file system. All operations are transactionally completed when they are comitted. This is done by means of three things: Copy-on-write for all changes, a tree-structure to the underlying data and meta-data and space allocation, and the ZIL - Eg the ZFS Intent Log. Going into these in depth are things you can read on in many posts on http://blogs.sun.com Hope this helps, _J ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS boot mirror
The second disk doesn't have the root pool on slice 2 - it is on slice 0 as with the first disk. All I did differently was to create a slice 2 covering the whole Solaris FDISK primary partition. If you then issue this command as before: installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/dsk/c5t1d0s0 (Note: slice ZERO) Then it will install grub onto that disk. You would need to ask someone else why it needs a slice 2 - I suspect that stage1 actually gets written to the first sector of the Solaris primary FDISK partition, hence it needs access to the special slice 2 to do that. Cheers Andrew. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] cron and roles (zfs-auto-snapshot 0.11 work)
My previous reply via email did not get linked to this post, so let me resend it: can roles run cron jobs ?), No. You need a user who can take on the role. Darn, back to the drawing board. I don't have all the context on this but Solaris RBAC roles *can* run cron jobs. Roles don't have to have users assigned to them. Roles normally have passwords and accounts that have valid passwords can run cron jobs. Sorry for the confusion and thanks for the clarification, I was thinking old nomenclature. Cron needs an *account*. 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-auto-snapshot: Use at ? SMF prop caching?
Hi Tim, So, I've got a pretty basic solution: Every time the service starts, we check for the existence of a snapshot [...] - if one doesn't exist, then we take a snapshot under the policy set down by that instance. This does sound like a valid alternative solution for this requirement if you want to avoid using at, though this will involve additional complexity for parsing timestamps of existing snapshots and calculating intervals, which I think is not that trivial in shells (consider timezone changes, leap years etc). Also, at can express intervals which are not expressible with crontabs, so keeping at schedules as an additional feature could be advantageous - which would be a solution to the shortcoming you have documented in the code: # Adding a cron job that runs exactly every x time-intervals is hard to do # properly. Hard to please everyone! If you felt like it, it'd be great to get the offset property working - that'd make the use of cron a lot more flexible for admins I think. OK, I'll let you know when (if) I start working on it so we don't do double work. Would the conditional-snapshot-on-start-method solution work for you? I think so, on the other hand I don't see why exactly you want to avoid supporting at as well. I've attached some sample code - see what you think. This is basically a simpler version of the same idea - put svcprops in variables. There are a couple of obstacles here: - If you create variables with the names of svc properties, you run into the issue that shell variables cant contain all characters valid for svc properties, which you need to work around then (you are using sed to filter out some characters (e.g. by mapping - to _), but this will make more than one svc- prop onto the same cache entry, which might work for zfs-auto-snapshot, but is not a general solution). My suggested code uses associative arrays which don't have this limitation. - For your solution, how do you invalidate the cache if a property is being changed or deleted (this is trivial, but not yet implemented)? - Does your solution handle white space, quotes etc. in svcprop values properly (I think there is an issue regarding white space, but I have not tested it)? - Does your solution impose a security risk? (consider the eval $NAME) Cheers, Nils 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 boot mirror
I have to say, looking at that confuses me a little. How can the two disks be mirrored when the partition tables don't match? On Sun, Aug 3, 2008 at 6:00 AM, andrew [EMAIL PROTECTED] wrote: OK, I've put up some screenshots and a copy of my menu.lst to clarify my setup: http://sites.google.com/site/solarium/zfs-screenshots Cheers Andrew. 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] are these errors dangerous
Ross wrote: Hi, First of all, I really should warn you that I'm very new to Solaris, I'll happily share my thoughts but be aware that there's not a lot of experience backing them up. From what you've said, and the logs you've posted I suspect you're hitting recoverable read errors. ZFS wouldn't flag these as no corrupt data has been encountered, but I suspect the device driver is logging them anyway. The log you posted all appears to refer to one disk (sd0), my guess would be that you have some hardware faults on that device and if it were me I'd probably be replacing it before it actually fails. I'd check your logs before replacing that disk though, you need to see if it's just that one disk, or if others are affected. Provided you have a redundant ZFS pool, it may be worth offlining that disk, unconfiguring it with cfgadm, and then pulling the drive to see if that does cure the warnings you're getting in the logs. Whatever you do, please keep me posted. Your post has already made me realise it would be a good idea to have a script watching log file sizes to catch problems like this early. Ross Thanks for your insights, I'm also relatively new to solaris but i've been on linux for years. I've just read more into the logs and its giving these errors for all 3 of my disks (sd0,1,2). I'm running a raidz1, unfortunately without any spares and I'm not too keen on removing the parity from my pool as I've got a lot of important files stored there. I would agree that this seems to be a recoverable error and nothing is getting corrupted thanks to ZFS. The thing I'm worried about is if the entire batch is failing slowly and will all die at the same time. Hopefully some ZFS/hardware guru can comment on this before the world ends for me :P Thanks Matt No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.10/1587 - Release Date: 02/08/2008 17:30 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Terrible zfs performance under NFS load
On Thu, 31 Jul 2008, Paul Fisher wrote: Syslog is funny in that it does a lot of open/write/close cycles so that rotate can work trivially. Those are meta-data updates and on NFS each implies a COMMIT. This leads us back to the old solaris nfs over zfs is slow discussion, where we talk about the fact that other nfs servers does not honor the COMMIT semantics and can lose data. I for one do *not* want solaris nfs/zfs to behave in any way other than it does. There is the additional problem that in order for the NFS client to update the log file, part of it needs to be read first. This results in a hit from needing to read a chunk of data in whatever blocksize ZFS decided to use. The entire chunk needs to be read from disk (could be cached in memory). Each read requires that the checksum be computed and verified. If the updates are small compared with the blocksize, then considerable resources are expended just computing the checksum. When the data is written back, the checksum needs to be computed for the new block. If ZFS does not update (enlarge) the head (tail?) block on the file, then it would end up using tiny block sizes leading to terrible fragmentation. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] are these errors dangerous
mh == Matt Harrison [EMAIL PROTECTED] writes: mh I'm worried about is if the entire batch is failing slowly mh and will all die at the same time. If you can download smartctl, you can use the approach described here: http://web.Ivy.NET/~carton/rant/ml/raid-findingBadDisks-0.html http://web.Ivy.NET/~carton/rant/ml/raid-findingBadDisks-1.html pgpM4oXv3mqyH.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Can I trust ZFS?
According to the hard disk drive guide at http://www.storagereview.com/guide2000/ref/hdd/index.html, a wopping 36% of data loss is due to human error. 49% of data loss was due to hardware or system malfunction. With proper pool design, zfs addresses most of the 49% of data loss due to hardware malfunction. You can do as much MTTDL analysis as you want based on drive reliability and read failure rates, but it still only addresses that 49% of data loss. Zfs makes human error really easy. For example $ zpool destroy mypool $ zfs destroy mypool/mydata The commands are almost instantaneous and are much faster than the classic: $ rm -rf /mydata or % newfs /dev/rdsk/c0t0d0s6 /dev/null Most problems we hear about on this list are due to one of these issues: * Human error * Beta level OS software * System memory error (particularly non-ECC memory) * Wrong pool design Zfs is a tool which can lead to exceptional reliability. Some forms of human error can be limited by facilities such as snapshots. System administrator human error is still a major factor. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Can I trust ZFS?
On Sun, 2008-08-03 at 11:42 -0500, Bob Friesenhahn wrote: Zfs makes human error really easy. For example $ zpool destroy mypool Note that zpool destroy can be undone by zpool import -D (if you get to it before the disks are overwritten). ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Setting up a zpool that can attached to a failover zone
Hi I have 2 Servers with zones. I have LUNs on a SAN that will contain application data which will be switched from zone A on Server 1 to zone A-failover on Server 2. What is the best way to set this up? I think that it should work if i create a zpool and use legacy mountpoints. I have to do the administration from the global zone and i still need vfstab. If I add the root dataset as a dataset to the zone configurations I won't be able to reboot the zone on the system that has not got the pool. But I think that I should delegate as much administration work to the zones. Or is it best to manage the pool in the global zone and make use of the -R option with relative zone mountpoints set? zfs set mountpoint=/path/in/zone poolname zpool import -R /path/to/zone/roo poolname Feedback is appreciated, Chris 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] are these errors dangerous
Hi Matt, If it's all 3 disks, I wouldn't have thought it likely to be disk errors, and I don't think it's a ZFS fault as such. You might be better posting the question in the storage or help forums to see if anybody there can shed more light on this. Ross Date: Sun, 3 Aug 2008 16:48:03 +0100 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] are these errors dangerous Ross wrote: Hi,First of all, I really should warn you that I'm very new to Solaris, I'll happily share my thoughts but be aware that there's not a lot of experience backing them up. From what you've said, and the logs you've posted I suspect you're hitting recoverable read errors. ZFS wouldn't flag these as no corrupt data has been encountered, but I suspect the device driver is logging them anyway. The log you posted all appears to refer to one disk (sd0), my guess would be that you have some hardware faults on that device and if it were me I'd probably be replacing it before it actually fails.I'd check your logs before replacing that disk though, you need to see if it's just that one disk, or if others are affected. Provided you have a redundant ZFS pool, it may be worth offlining that disk, unconfiguring it with cfgadm, and then pulling the drive to see if that does cure the warnings you're getting in the logs.Whatever you do, please keep me posted. Your post has already made me realise it would be a good idea to have a script watching log file sizes to catch problems like this early.Ross Thanks for your insights, I'm also relatively new to solaris but i've been on linux for years. I've just read more into the logs and its giving these errors for all 3 of my disks (sd0,1,2). I'm running a raidz1, unfortunately without any spares and I'm not too keen on removing the parity from my pool as I've got a lot of important files stored there. I would agree that this seems to be a recoverable error and nothing is getting corrupted thanks to ZFS. The thing I'm worried about is if the entire batch is failing slowly and will all die at the same time. Hopefully some ZFS/hardware guru can comment on this before the world ends for me :P Thanks Matt No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.10/1587 - Release Date: 02/08/2008 17:30 _ Win a voice over part with Kung Fu Panda Live Search and 100’s of Kung Fu Panda prizes to win with Live Search http://clk.atdmt.com/UKM/go/107571439/direct/01/___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] are these errors dangerous
Miles Nordin wrote: mh == Matt Harrison [EMAIL PROTECTED] writes: mh I'm worried about is if the entire batch is failing slowly mh and will all die at the same time. If you can download smartctl, you can use the approach described here: http://web.Ivy.NET/~carton/rant/ml/raid-findingBadDisks-0.html http://web.Ivy.NET/~carton/rant/ml/raid-findingBadDisks-1.html I already had smartmontools for temp monitoring. using smartctl -a I get : Device supports SMART and is Enabled Temperature Warning Disabled or Not Supported SMART Health Status: OK Current Drive Temperature: 33 C Error Counter logging not supported unhelpful No self-tests have been logged So it looks like I can't use the error count on these (sata) drives. Otherwise everything else looks ok for all 3. And regard Ross' reply, I will try posting something to storage-discuss and see if anyone has more ideas. thanks Matt No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.10/1587 - Release Date: 02/08/2008 17:30 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Scrubbing only checks used data?
Hi there, I am currently evaluating OpenSolaris as a replacement for my linux installations. I installed it as a xen domU, so there is a remote chance, that my observations are caused by xen. First, my understanding of zpool [i]scrub[/i] is Ok, go ahead, and rewrite [b]each block of each device[/b] of the zpool. Whereas [i]resilvering[/i] means Make sure, that all [b]used blocks[/b] of the pool are in good health. Please correct me, if I am wrong. To test, I created a zpool named tank, assigning it a whole 300GB physical SATA disc as backend. I observed, that scrubbing my 300GB tank takes virtually no time, when tank is empty. Using space of tank (say, by a 20 GB copy of /dev/zero) causes scrubbing to take much longer. This is clearly not, what I want (now). I want zfs to check the whole device for errors, not just the few bytes that happen to sit there. Is this a bug, a misunderstanding or a terrible case of RTFM? Another irrirating observation was, that scrubbing starts, then stalls for a minute or so at 0.4 something percent and then continues. Any ideas / pointers / ... ? Jens --- bash-3.2# zpool status tank pool: tank state: ONLINE scrub: scrub completed after 0h0m with 0 errors on Sun Aug 3 18:46:51 2008 config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 c4d1 ONLINE 0 0 0 errors: No known data errors bash-3.2# uname -X System = SunOS Node = opensolaris Release = 5.11 KernelID = snv_94 Machine = i86pc BusType = unknown Serial = unknown Users = unknown OEM# = 0 Origin# = 1 NumCPU = 1 bash-3.2# cat /etc/release OpenSolaris 2008.11 snv_94 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 17 July 2008 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] are these errors dangerous
On Sun, Aug 3, 2008 at 8:48 PM, Matt Harrison [EMAIL PROTECTED]wrote: Miles Nordin wrote: mh == Matt Harrison [EMAIL PROTECTED] writes: mh I'm worried about is if the entire batch is failing slowly mh and will all die at the same time. Matt, can you please post the output from this command: iostat -E This will show counts of the types of errors for all disks since the last reboot. I am guessing sd0 is your CD / DVD drive. Thank you, _Johan -- Any sufficiently advanced technology is indistinguishable from magic. Arthur C. Clarke Afrikaanse Stap Website: http://www.bloukous.co.za My blog: http://initialprogramload.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Disabling disks' write-cache in J4200 with ZFS?
Todd E. Moore wrote: I'm working with a group that wants to commit all the way to disk every single write - flushing or bypassing all the caches each time. The fsync() call will flush the ZIL. As for the disk's cache, if given the entire disk, ZFS enables its cache by default. Rather than ZFS having to issue the flush command to the disk we want to disable this cache and avoid the step altogether Actually, it will flush to the ZIL. If you don't want the disk's cache enabled by default, then use a slice. None of this is difficult. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] are these errors dangerous
Matt Harrison wrote: Hi everyone, I've been running a zfs fileserver for about a month now (on snv_91) and it's all working really well. I'm scrubbing once a week and nothing has come up as a problem yet. I'm a little worried as I've just noticed these messages in /var/adm/message and I don't know if they're bad or just informational: Aug 2 14:46:06 exodus Error for Command: read_defect_dataError Level: Informational key here: Informational Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Requested Block: 0 Error Block: 0 Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Vendor: ATA Serial Number: Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Sense Key: Illegal_Request Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]ASC: 0x20 (invalid command operation code), ASCQ: 0x0, FRU: 0x0 Key here: ASC 0x20 (invalid command operation code) Aug 2 14:46:06 exodus scsi: [ID 107833 kern.warning] WARNING: /[EMAIL PROTECTED],0/pci1043,[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (sd0): Aug 2 14:46:06 exodus Error for Command: log_sense Error Level: Informational Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Requested Block: 0 Error Block: 0 Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Vendor: ATA Serial Number: Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Sense Key: Illegal_Request Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]ASC: 0x24 (invalid field in cdb), ASCQ: 0x0, FRU: 0x0 Key here: invalid field in cbd where CDB is command data block http://en.wikipedia.org/wiki/SCSI_CDB Obviously a command is being sent to the device that it doesn't understand. This could be a host side driver or disk firmware problem. I'd classify this as annoying, but doesn't appear dangerous on the face. With some digging you could determine which command is failing, but that won't fix anything. You might check with the disk vendor for firmware upgrades and you might look at a later version of the OS drivers. This isn't a ZFS issue, so you might have better luck on the storage-discuss forum. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] are these errors dangerous
Johan Hartzenberg wrote: On Sun, Aug 3, 2008 at 8:48 PM, Matt Harrison [EMAIL PROTECTED]wrote: Miles Nordin wrote: mh == Matt Harrison [EMAIL PROTECTED] writes: mh I'm worried about is if the entire batch is failing slowly mh and will all die at the same time. Matt, can you please post the output from this command: iostat -E [EMAIL PROTECTED]:~ # iostat -E cmdk0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Model: WDC WD2000JB-00 Revision: Serial No: WD-WCAL81632817 Size: 200.05GB 200047067136 bytes Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 0 sd0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: WDC WD7500AAKS-0 Revision: 4G30 Serial No: Size: 750.16GB 750156374016 bytes Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 478675 Predictive Failure Analysis: 0 sd1 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: WDC WD7500AAKS-0 Revision: 4G30 Serial No: Size: 750.16GB 750156374016 bytes Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 478626 Predictive Failure Analysis: 0 sd2 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: ATA Product: WDC WD7500AAKS-0 Revision: 4G30 Serial No: Size: 750.16GB 750156374016 bytes Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0 Illegal Request: 478604 Predictive Failure Analysis: 0 sd3 Soft Errors: 0 Hard Errors: 16 Transport Errors: 0 Vendor: HL-DT-ST Product: DVDRAM_GSA-H10N Revision: JX06 Serial No: Size: 0.00GB 0 bytes Media Error: 0 Device Not Ready: 16 No Device: 0 Recoverable: 0 Illegal Request: 0 Predictive Failure Analysis: 0 Lots of illegal requests, and a few hard errors. Doesn't look good. This will show counts of the types of errors for all disks since the last reboot. I am guessing sd0 is your CD / DVD drive. I don't think so, my dvd drive is on ide along with the boot drive, while my pool is on 3 SATA disks. Thanks Matt No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.10/1587 - Release Date: 02/08/2008 17:30 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] are these errors dangerous
Richard Elling wrote: Matt Harrison wrote: Aug 2 14:46:06 exodus Error for Command: read_defect_data Error Level: Informational key here: Informational Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Requested Block: 0 Error Block: 0 Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Vendor: ATA Serial Number: Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Sense Key: Illegal_Request Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]ASC: 0x20 (invalid command operation code), ASCQ: 0x0, FRU: 0x0 Key here: ASC 0x20 (invalid command operation code) Aug 2 14:46:06 exodus scsi: [ID 107833 kern.warning] WARNING: /[EMAIL PROTECTED],0/pci1043,[EMAIL PROTECTED]/[EMAIL PROTECTED],0 (sd0): Aug 2 14:46:06 exodus Error for Command: log_sense Error Level: Informational Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Requested Block: 0 Error Block: 0 Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Vendor: ATA Serial Number: Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]Sense Key: Illegal_Request Aug 2 14:46:06 exodus scsi: [ID 107833 kern.notice]ASC: 0x24 (invalid field in cdb), ASCQ: 0x0, FRU: 0x0 Key here: invalid field in cbd where CDB is command data block http://en.wikipedia.org/wiki/SCSI_CDB Obviously a command is being sent to the device that it doesn't understand. This could be a host side driver or disk firmware problem. I'd classify this as annoying, but doesn't appear dangerous on the face. With some digging you could determine which command is failing, but that won't fix anything. You might check with the disk vendor for firmware upgrades and you might look at a later version of the OS drivers. Well I'm pleased it doesn't scream DANGER to people. I can live with clearing out the logs now and then. I will check with WD if there are firmware updates for these disks, and I will update my snv at some point. This isn't a ZFS issue, so you might have better luck on the storage-discuss I have posted to storage-discuss a little while ago. I'm not even sure why I posted here in the first place, storage-discuss would be a much better idea. Thanks Matt No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.10/1587 - Release Date: 02/08/2008 17:30 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Scrubbing only checks used data?
Jens wrote: Hi there, I am currently evaluating OpenSolaris as a replacement for my linux installations. I installed it as a xen domU, so there is a remote chance, that my observations are caused by xen. First, my understanding of zpool [i]scrub[/i] is Ok, go ahead, and rewrite [b]each block of each device[/b] of the zpool. There are two types of scrub: read and rewrite. Read scrubs just check data and make sure it is still readable. Rewrite scrubs do the read check, then rewrite the data thus resetting the superparamagnetic decay counter. ZFS does a read scrub. Whereas [i]resilvering[/i] means Make sure, that all [b]used blocks[/b] of the pool are in good health. The term resilvering comes from the mirror making process (the reflective coating on real mirrors is called silver, so by resilivering a mirror you correct any defects in the reflective coating. Some liberties are used when thus describing mirrored disks, where the term resilver refers to the process of making both sides of the mirror the same. Data is copied from one side of the mirror to the other. Astute readers will recognize this as an opportunity for failures, and they would be correct, but that is another blog... Another term often used here is resync, which is perhaps a more general term where we make something in sync with something else, from a data perspective when we're talking about storage. Please correct me, if I am wrong. To test, I created a zpool named tank, assigning it a whole 300GB physical SATA disc as backend. I observed, that scrubbing my 300GB tank takes virtually no time, when tank is empty. Using space of tank (say, by a 20 GB copy of /dev/zero) causes scrubbing to take much longer. Yep. ZFS will only scrub data. An empty pool has very little data, so it will complete quickly. A full file system will take longer. This is actually one of the big advantages of ZFS over other RAID systems which have no understanding of where the data actually is. RAID arrays, for example, will scrub an entire disk because they don't know what parts of the disk actually contain data. This is clearly not, what I want (now). I want zfs to check the whole device for errors, not just the few bytes that happen to sit there. Is this a bug, a misunderstanding or a terrible case of RTFM? ZFS won't do this, because it is only really concerned with data. There are other ways to check media. For example the format command will allow you do to non-destructive or destructive media tests. I recommend non-destructive tests, normally. Another irrirating observation was, that scrubbing starts, then stalls for a minute or so at 0.4 something percent and then continues. Since ZFS is dynamic, its ability to determine how long a scrub will take is somewhat imprecise. With later builds, ZFS records how long it actually took, which might be a better predictor for future scrubs (see below) -- richard Any ideas / pointers / ... ? Jens --- bash-3.2# zpool status tank pool: tank state: ONLINE scrub: scrub completed after 0h0m with 0 errors on Sun Aug 3 18:46:51 2008 config: NAMESTATE READ WRITE CKSUM tankONLINE 0 0 0 c4d1 ONLINE 0 0 0 errors: No known data errors bash-3.2# uname -X System = SunOS Node = opensolaris Release = 5.11 KernelID = snv_94 Machine = i86pc BusType = unknown Serial = unknown Users = unknown OEM# = 0 Origin# = 1 NumCPU = 1 bash-3.2# cat /etc/release OpenSolaris 2008.11 snv_94 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 17 July 2008 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] ZFS boot mirror
Malachi de Ælfweald wrote: I have to say, looking at that confuses me a little. How can the two disks be mirrored when the partition tables don't match? Welcome to ZFS! In traditional disk mirrors, disk A block 0 == disk B block 0 disk A block 1 == disk B block 1 ... disk A block N == disk B block N In a ZFS world, block 1 might be defective. So ZFS will reallocate the block somewhere else. This is great for reliable storage on unreliable devices (disks). It also relieves you from the expectation that the partition tables must match. And it also means that I can grow the pool size by replacing the mirror sides with larger devices. Life is good! Enjoy! -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] how to make two disks of one pool mirror both readable separately.
there are two disks in one ZFS pool used as mirror. So we all know that there are the same date on the two disks. I want to know, how can migrate them into two separate pools, so I can later read write them separately.( just as in UFS mirror, we can mount each separately). thanks. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] help me....
hi can you give some disadvantages of the ZFS file system?? plzz its urgent... help me. 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] help me....
On Sun, 2008-08-03 at 20:46 -0700, Rahul wrote: hi can you give some disadvantages of the ZFS file system?? In what context ? Relative to what ? Bob ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] help me....
On Sun, 3 Aug 2008, Rahul wrote: hi can you give some disadvantages of the ZFS file system?? Yes. It provides very poor performance for large-file random-access read/write of 128 bytes at a time. Is that enough info? ZFS is great but it is not perfect in every regard. It is easy to build a list of problems to be solved but they can't be listed as disadvantages since they are not solved elsewhere either (or simply don't apply). Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] help me....
Rahul wrote: hi can you give some disadvantages of the ZFS file system?? Yes, it's too easy to administer. This makes it rough to charge a lot as a sysadmin. All the problems, manual decisions during fsck and data recovery, head-aches after a power failure or getting disk drives mixed up after replacing a controller, not any more. Not with ZFS. It's just not fair It's really hard to charge a lot to take care of a zfs system. plzz its urgent... help me. 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
