Why doesn''t "zpool status -v" display the byte ranges of permanent errors anymore, like it used to (before snv_57)? I think it was a useful feature. For example, I have a pool with 17 permanent errors in 2 files with 700 MB each, but no ability to see directly which one has the most errors or which byte ranges are affected (I happen to know that one of them only has 1 error, so I suppose the other one has 16 errors). Any particular reason why this feature was removed? Thanks.
On Apr 19, 2007, at 1:38 AM, Ricardo Correia wrote:> Why doesn''t "zpool status -v" display the byte ranges of permanent > errors anymore, like it used to (before snv_57)? > > I think it was a useful feature. For example, I have a pool with 17 > permanent errors in 2 files with 700 MB each, but no ability to see > directly which one has the most errors or which byte ranges are > affected > (I happen to know that one of them only has 1 error, so I suppose the > other one has 16 errors). > > Any particular reason why this feature was removed?Two reasons: 1) cluttered the output (as the path name is variable length). We could perhaps add another flag (-V or -vv or something) to display the ranges. 2) i wasn''t convinced that output was useful, especially to most users/admins. If we did provide the range information, how would you actually use that information? or would providing the number of checksum errors per file be what you''re really looking for? eric ps: could you send me the ''zpool status -v'' output for curiosity''s sake
eric kustarz wrote:> Two reasons: > 1) cluttered the output (as the path name is variable length). We > could perhaps add another flag (-V or -vv or something) to display the > ranges. > 2) i wasn''t convinced that output was useful, especially to most > users/admins. > > If we did provide the range information, how would you actually use > that information? > > or would providing the number of checksum errors per file be what > you''re really looking for? >I agree that the current display is more appropriate as a default. But yes, I think adding a -vv flag to show the range output would be useful. It seems interesting from an observability standpoint, since I could easily tell how much damage did the file get. Simply telling the number of checksum errors per file would be useful too, but not as useful it was since each checksum error can be between 512 bytes and 128 KB.> ps: could you send me the ''zpool status -v'' output for curiosity''s sakeSure :) wizeman at wizy-laptop:~/zfs/repos/trunk/src/zfs-fuse$ sudo zpool status -v pool: pen state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed with 22 errors on Thu Apr 19 16:31:56 2007 config: NAME STATE READ WRITE CKSUM pen ONLINE 0 0 44 sdb2 ONLINE 0 0 44 errors: Permanent errors have been detected in the following files: /pen/compr/vmware-img.tar /pen/compr2/vmware-img.tar pool: ruben state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed with 1 errors on Thu Apr 19 16:33:04 2007 config: NAME STATE READ WRITE CKSUM ruben ONLINE 0 0 106 sda ONLINE 0 0 106 errors: Permanent errors have been detected in the following files: /ruben/ptwiki-20060916-pages-meta-history.xml.7z Aren''t USB pen drives great? (not!) For curiosity sake, that "pen" pool is in a 2 GB partition inside a 4 GB pen drive I bought recently, and both vmware-img.tar files have around 750 MB each. The "ruben" pool is a *very flaky* 128 MB pen drive that a friend gave to me since it was completely unusable with other filesystems. For the record, in this filesystem, I set copies=3, filled the pool with random files and even then the scrub found 1 permanent error!
On Apr 19, 2007, at 12:50 PM, Ricardo Correia wrote:> eric kustarz wrote: >> Two reasons: >> 1) cluttered the output (as the path name is variable length). We >> could perhaps add another flag (-V or -vv or something) to display >> the >> ranges. >> 2) i wasn''t convinced that output was useful, especially to most >> users/admins. >> >> If we did provide the range information, how would you actually use >> that information? >> >> or would providing the number of checksum errors per file be what >> you''re really looking for? >> > > I agree that the current display is more appropriate as a default. > But yes, I think adding a -vv flag to show the range output would be > useful. It seems interesting from an observability standpoint, since I > could easily tell how much damage did the file get. Simply telling the > number of checksum errors per file would be useful too, but not as > useful it was since each checksum error can be between 512 bytes > and 128 KB.I agree it would be interesting (especially for us developers). What i''m curious is (and anyone can answer), what action would you take (or not take) based on this additional information?> >> ps: could you send me the ''zpool status -v'' output for curiosity''s >> sake > Sure :)thanks... eric