[zfs-discuss] SEEK_HOLE returns the whole sparse file size?
Hello List, I am trying to fetch the data/hole info of a sparse file through the lseek(SEEK_HOLE/SEEK_DATA) stuff, the result of fpathconf(..., _PC_MIN_HOLE_SIZE) is ok, so I think this interface is supported on my testing ZFS, but SEEK_HOLE always return the sparse file total size instead of the desired first hole start offset. The whole process was shown as following, Could anyone give any hints? Create a sparse file("sparse2") as below, SEEK_HOLE should returns *ZERO* and SEEK_DATA should returns 40960 IMHO: bash-3.00@ python -c "f=open('sparse2', 'w'); f.seek(40960); f.write('BYE'); f.close()" A tiny program to examine the hole start offset of file "sparse2". #include #include #include #include #include #include #include int main(int argc, char *argv[]) { int ret = 0, fd; off_t data_pos, hole_pos; const char *filename = NULL; if (argc != 2) { fprintf(stderr, "Usage: %s file\n", argv[0]); return 1; } filename = strdup(argv[1]); if (!filename) { perror("strdup"); return -1; } fd = open(filename, O_RDONLY); if (fd < 0) { perror("open"); ret = -1; goto out; } if (fpathconf(fd, _PC_MIN_HOLE_SIZE) < 0) { fprintf(stderr, "The underlying filesystem does not support SEEK_HOLE.\n"); goto out; } hole_pos = lseek(fd, (off_t)0, SEEK_HOLE); if (hole_pos < 0) { if (errno == EINVAL || errno == ENOTSUP) { fprintf(stderr, "SEEK_HOLE does not support on OS or filesystem.\n"); goto out; } perror("lseek"); ret = -1; goto out; } if (hole_pos == 0) fprintf(stderr, "Oh, no!! hole start at offset 0?\n"); if (hole_pos > 0) fprintf(stderr, "detected a real hole at: %d.\n", hole_pos); out: free(filename); lseek(fd, (off_t)0, SEEK_SET); return 0; } My test env: bash-3.00# uname -a SunOS unknown 5.10 Generic_142910-17 i86pc i386 i86pc man zfs(1): SunOS 5.10 Last change: 11 Jun 2010 bash-3.00# zfs list NAMEUSED AVAIL REFER MOUNTPOINT ... ... rpool/export/home 120K 139G 120K /export/home ... "sparse2" located at "/export/home": bash-3.00# zdb -dd rpool/export/home Object lvl iblk dblk dsize lsize %full type 104116K 40.5K 40.5K 40.5K 100.00 ZFS plain file 264 bonus ZFS znode dnode flags: USED_BYTES USERUSED_ACCOUNTED dnode maxblkid: 0 path/sparse2 uid 0 gid 0 atime Mon Apr 18 14:50:46 2011 mtime Mon Apr 18 14:50:46 2011 ctime Mon Apr 18 14:50:46 2011 crtime Mon Apr 18 14:50:46 2011 gen 497 mode100600 size40963 parent 3 links 1 xattr 0 rdev0x Indirect blocks: 0 L0 0:1960ce000:a200 a200L/a200P F=1 B=497/497 segment [, a200) size 40.5K bash-3.00# zdb -R rpool/export/home 0:1960ce000:a200 . 009ff0: 00a000: 00455942 BYE. 00a010: ... Any comments are appreciated! Thanks, -Jeff ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] SEEK_HOLE returns the whole sparse file size?
On Apr 18, 2011, at 11:22 AM, jeff.liu wrote: > Hello List, > > I am trying to fetch the data/hole info of a sparse file through the > lseek(SEEK_HOLE/SEEK_DATA) > stuff, the result of fpathconf(..., _PC_MIN_HOLE_SIZE) is ok, so I think this > interface is supported > on my testing ZFS, but SEEK_HOLE always return the sparse file total size > instead of the desired > first hole start offset. > > The whole process was shown as following, Could anyone give any hints? > > Create a sparse file("sparse2") as below, SEEK_HOLE should returns *ZERO* and > SEEK_DATA should > returns 40960 IMHO: > bash-3.00@ python -c "f=open('sparse2', 'w'); f.seek(40960); f.write('BYE'); > f.close()" With default settings you'll get single-block file without any holes from ZFS perspective. Try somewhat bigger sparse file like this: dd if=/dev/urandom of=test.file count=1 bs=128k oseek=1024 > > A tiny program to examine the hole start offset of file "sparse2". > #include > #include > #include > #include > #include > #include > #include > > int > main(int argc, char *argv[]) > { > int ret = 0, fd; > off_t data_pos, hole_pos; > const char *filename = NULL; > > if (argc != 2) { > fprintf(stderr, "Usage: %s file\n", argv[0]); > return 1; > } > > filename = strdup(argv[1]); > if (!filename) { > perror("strdup"); > return -1; > } > > fd = open(filename, O_RDONLY); > if (fd < 0) { > perror("open"); > ret = -1; > goto out; > } > > if (fpathconf(fd, _PC_MIN_HOLE_SIZE) < 0) { > fprintf(stderr, "The underlying filesystem does not support > SEEK_HOLE.\n"); > goto out; > } > > hole_pos = lseek(fd, (off_t)0, SEEK_HOLE); > if (hole_pos < 0) { > if (errno == EINVAL || errno == ENOTSUP) { > fprintf(stderr, "SEEK_HOLE does not support on OS or > filesystem.\n"); > goto out; > } > > perror("lseek"); > ret = -1; > goto out; > } > > if (hole_pos == 0) > fprintf(stderr, "Oh, no!! hole start at offset 0?\n"); > > if (hole_pos > 0) > fprintf(stderr, "detected a real hole at: %d.\n", hole_pos); > > out: > free(filename); > lseek(fd, (off_t)0, SEEK_SET); > > return 0; > } > > My test env: > > bash-3.00# uname -a > SunOS unknown 5.10 Generic_142910-17 i86pc i386 i86pc > > man zfs(1): > SunOS 5.10 Last change: 11 Jun 2010 > > bash-3.00# zfs list > NAMEUSED AVAIL REFER MOUNTPOINT > ... > ... > rpool/export/home 120K 139G 120K /export/home > ... > > "sparse2" located at "/export/home": > bash-3.00# zdb -dd rpool/export/home > Object lvl iblk dblk dsize lsize %full type > 104116K 40.5K 40.5K 40.5K 100.00 ZFS plain file > 264 bonus ZFS znode > dnode flags: USED_BYTES USERUSED_ACCOUNTED > dnode maxblkid: 0 > path/sparse2 > uid 0 > gid 0 > atime Mon Apr 18 14:50:46 2011 > mtime Mon Apr 18 14:50:46 2011 > ctime Mon Apr 18 14:50:46 2011 > crtime Mon Apr 18 14:50:46 2011 > gen 497 > mode100600 > size40963 > parent 3 > links 1 > xattr 0 > rdev0x > Indirect blocks: > 0 L0 0:1960ce000:a200 a200L/a200P F=1 B=497/497 > > segment [, a200) size 40.5K > > bash-3.00# zdb -R rpool/export/home 0:1960ce000:a200 > . > 009ff0: > 00a000: 00455942 BYE. > 00a010: > > ... > > Any comments are appreciated! > > Thanks, > -Jeff > ___ > 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] SEEK_HOLE returns the whole sparse file size?
Victor Latushkin wrote: > On Apr 18, 2011, at 11:22 AM, jeff.liu wrote: > >> Hello List, >> >> I am trying to fetch the data/hole info of a sparse file through the >> lseek(SEEK_HOLE/SEEK_DATA) >> stuff, the result of fpathconf(..., _PC_MIN_HOLE_SIZE) is ok, so I think >> this interface is supported >> on my testing ZFS, but SEEK_HOLE always return the sparse file total size >> instead of the desired >> first hole start offset. >> >> The whole process was shown as following, Could anyone give any hints? >> >> Create a sparse file("sparse2") as below, SEEK_HOLE should returns *ZERO* >> and SEEK_DATA should >> returns 40960 IMHO: >> bash-3.00@ python -c "f=open('sparse2', 'w'); f.seek(40960); f.write('BYE'); >> f.close()" > > With default settings you'll get single-block file without any holes from ZFS > perspective. > > Try somewhat bigger sparse file like this: > > dd if=/dev/urandom of=test.file count=1 bs=128k oseek=1024 Thanks for your quick response! It works for me now. Regards, -Jeff > > >> A tiny program to examine the hole start offset of file "sparse2". >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> int >> main(int argc, char *argv[]) >> { >> int ret = 0, fd; >> off_t data_pos, hole_pos; >> const char *filename = NULL; >> >> if (argc != 2) { >> fprintf(stderr, "Usage: %s file\n", argv[0]); >> return 1; >> } >> >> filename = strdup(argv[1]); >> if (!filename) { >> perror("strdup"); >> return -1; >> } >> >> fd = open(filename, O_RDONLY); >> if (fd < 0) { >> perror("open"); >> ret = -1; >> goto out; >> } >> >> if (fpathconf(fd, _PC_MIN_HOLE_SIZE) < 0) { >> fprintf(stderr, "The underlying filesystem does not support >> SEEK_HOLE.\n"); >> goto out; >> } >> >> hole_pos = lseek(fd, (off_t)0, SEEK_HOLE); >> if (hole_pos < 0) { >> if (errno == EINVAL || errno == ENOTSUP) { >> fprintf(stderr, "SEEK_HOLE does not support on OS or >> filesystem.\n"); >> goto out; >> } >> >> perror("lseek"); >> ret = -1; >> goto out; >> } >> >> if (hole_pos == 0) >> fprintf(stderr, "Oh, no!! hole start at offset 0?\n"); >> >> if (hole_pos > 0) >> fprintf(stderr, "detected a real hole at: %d.\n", hole_pos); >> >> out: >> free(filename); >> lseek(fd, (off_t)0, SEEK_SET); >> >> return 0; >> } >> >> My test env: >> >> bash-3.00# uname -a >> SunOS unknown 5.10 Generic_142910-17 i86pc i386 i86pc >> >> man zfs(1): >> SunOS 5.10 Last change: 11 Jun 2010 >> >> bash-3.00# zfs list >> NAMEUSED AVAIL REFER MOUNTPOINT >> ... >> ... >> rpool/export/home 120K 139G 120K /export/home >> ... >> >> "sparse2" located at "/export/home": >> bash-3.00# zdb -dd rpool/export/home >> Object lvl iblk dblk dsize lsize %full type >> 104116K 40.5K 40.5K 40.5K 100.00 ZFS plain file >> 264 bonus ZFS znode >> dnode flags: USED_BYTES USERUSED_ACCOUNTED >> dnode maxblkid: 0 >> path/sparse2 >> uid 0 >> gid 0 >> atime Mon Apr 18 14:50:46 2011 >> mtime Mon Apr 18 14:50:46 2011 >> ctime Mon Apr 18 14:50:46 2011 >> crtime Mon Apr 18 14:50:46 2011 >> gen 497 >> mode100600 >> size40963 >> parent 3 >> links 1 >> xattr 0 >> rdev0x >> Indirect blocks: >> 0 L0 0:1960ce000:a200 a200L/a200P F=1 B=497/497 >> >> segment [, a200) size 40.5K >> >> bash-3.00# zdb -R rpool/export/home 0:1960ce000:a200 >> . >> 009ff0: >> 00a000: 00455942 BYE. >> 00a010: >> >> ... >> >> Any comments are appreciated! >> >> Thanks, >> -Jeff >> ___ >> 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] SEEK_HOLE returns the whole sparse file size?
"jeff.liu" wrote: > Hello List, > > I am trying to fetch the data/hole info of a sparse file through the > lseek(SEEK_HOLE/SEEK_DATA) > stuff, the result of fpathconf(..., _PC_MIN_HOLE_SIZE) is ok, so I think this > interface is supported > on my testing ZFS, but SEEK_HOLE always return the sparse file total size > instead of the desired > first hole start offset. Maybe you did not create the file correctly. If you like to create a file of a specific size that only contains one single hole, there is a way to do this using star: mkfile some-file # create a file of the desired size star -c f=xx.tar -meta some-file# archive the meta data only rm some-file# remove original file star -x -xmeta -force-hole f=xx.tar # let star create an empty file of the # same size This will try to create a file that has one hole but no data in case the filesystem supports to do this. For UFS, such a file e.g. needs to be a multiple of 8k in size. This is because holes in UFS need to be aligned at 8k boundaries and need to be a multiple of 8k in size. A recent star can be found in the schily source consolidation: ftp://ftp.berlios.de/pub/schily/ star is part of Schillix-ON (a free OpenSolaris fork). Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [storage-discuss] zfs over iscsi not recovering from timeouts
Hi Tuomas: Before you run "zpool clear", please make sure that the os device name exists in the output of 'iscsiadm list target -S'. #iscsiadm list target -S Target: iqn.1986-03.com.sun:02:test Alias: - TPGT: 1 ISID: 402a Connections: 1 LUN: 0 Vendor: SUN Product: COMSTAR OS Device Name: /dev/rdsk/c0t600144F008002797ACDE4CCBC0480001d0s2
Re: [zfs-discuss] SEEK_HOLE returns the whole sparse file size?
在 2011-4-18,下午6:03, Joerg Schilling 写道: > "jeff.liu" wrote: > >> Hello List, >> >> I am trying to fetch the data/hole info of a sparse file through the >> lseek(SEEK_HOLE/SEEK_DATA) >> stuff, the result of fpathconf(..., _PC_MIN_HOLE_SIZE) is ok, so I think >> this interface is supported >> on my testing ZFS, but SEEK_HOLE always return the sparse file total size >> instead of the desired >> first hole start offset. > > Maybe you did not create the file correctly. > > If you like to create a file of a specific size that only contains one single > hole, there is a way to do this using star: > > mkfile some-file # create a file of the desired > size > star -c f=xx.tar -meta some-file # archive the meta data only > rm some-file # remove original file > star -x -xmeta -force-hole f=xx.tar # let star create an empty file of the > # same size > > This will try to create a file that has one hole but no data in case the > filesystem supports to do this. > > For UFS, such a file e.g. needs to be a multiple of 8k in size. This is > because > holes in UFS need to be aligned at 8k boundaries and need to be a multiple of > 8k in size. > > > A recent star can be found in the schily source consolidation: > > ftp://ftp.berlios.de/pub/schily/ > > > star is part of Schillix-ON (a free OpenSolaris fork). Thanks for your info! Actually, I'd like to create a sparse file with both data and holes to test a patch I am working on, it was wrote for Coreutils to optimize sparse file reading, especially for cp(1). I had took a look at the source code of Star before, and I was wondering of comments at start/hole.c: sparse_file(fp, info) at that time, line: 1240if (pos >= info->f_size) { /* Definitely not sparse */ Now, I am still not sure why the returned 'pos' could larger than 'info->f_size' in some cases, I guess it should be equal to the f_size if the target file is not sparse, Am I missing something here? For the sparse file I created via python -c "f=open('sparse', 'w'); f.seek(40960); f.write('BYE'); f.close()", IMHO, it is a right way to create a sparse file conventionally, but it is too small to spanning across multiple blocks, so ZFS allocate it as an non-sparse single block file just as Victor's response. Regards, -Jeff > > Jörg > > -- > EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin > j...@cs.tu-berlin.de(uni) > joerg.schill...@fokus.fraunhofer.de (work) Blog: > http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Bootable root pool?
Hi, As I understand it there were restrictions on a bootable root pool where it cannot be defined to use whole-disk configurations for a single disk, or multiple disks which are mirrored. Does it still apply that you need to define such pools as using slices, ie. by either defining a partition (if non-SPARC) and then a slice 0? i.e. zpool create mirror c1t0d0 c1t1d0# not bootable while zpool create mirror c1t0d0s0 c1t1d0s0# IS bootable Is it possible to use cache and log devices in a root pool? If so, does this restriction on the use of a slice rather than just the disk device also apply here? i.e. would the following be supported: zpool create mirror c1t0d0s0 c1t1d0s0 cache c2t0d0 log c2t1d0 Thanks, Darren. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Bootable root pool?
Hi Darren, Yes, a bootable root pool must be created on a disk slice. You can use a cache device, but not a log device, and the cache device must be a disk slice. See the output below. Thanks, Cindy # zpool add rpool log c0t2d0s0 cannot add to 'rpool': root pool can not have multiple vdevs or separate logs # zpool add rpool cache c0t3d0 cannot label 'c0t3d0': EFI labeled devices are not supported on root pools. # zpool add rpool cache c0t3d0s0 # zpool status rpool pool: rpool state: ONLINE scan: none requested config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 c0t0d0s0 ONLINE 0 0 0 cache c0t3d0s0 ONLINE 0 0 0 errors: No known data errors On 04/18/11 10:22, Darren Kenny wrote: Hi, As I understand it there were restrictions on a bootable root pool where it cannot be defined to use whole-disk configurations for a single disk, or multiple disks which are mirrored. Does it still apply that you need to define such pools as using slices, ie. by either defining a partition (if non-SPARC) and then a slice 0? i.e. zpool create mirror c1t0d0 c1t1d0# not bootable while zpool create mirror c1t0d0s0 c1t1d0s0# IS bootable Is it possible to use cache and log devices in a root pool? If so, does this restriction on the use of a slice rather than just the disk device also apply here? i.e. would the following be supported: zpool create mirror c1t0d0s0 c1t1d0s0 cache c2t0d0 log c2t1d0 Thanks, Darren. ___ 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] zpool scrub on b123
So i figured out after a couple of scrubs and fmadm faulty that drive c9t15d0 was bad. I then replaced the drive using -bash-3.2$ pfexec /usr/sbin/zpool offline vdipool c9t15d0 -bash-3.2$ pfexec /usr/sbin/zpool replace vdipool c9t15d0 c9t19d0 The drive resilvered and I rebooted the server, just to make sure everything was clean. After the reboot, zfs resilvred the same drive again(which took 7hrs) My pool now looks like this: NAME STATE READ WRITE CKSUM vdipoolDEGRADED 0 0 2 raidz1 DEGRADED 0 0 4 c9t14d0ONLINE 0 0 1 512 resilvered spare DEGRADED 0 0 0 c9t15d0 OFFLINE 0 0 0 c9t19d0 ONLINE 0 0 0 16.1G resilvered c9t16d0ONLINE 0 0 1 512 resilvered c9t17d0ONLINE 0 0 5 2.50K resilvered c9t18d0ONLINE 0 0 1 512 resilvered spares c9t19d0 INUSE currently in use I'm going to replace c9t15d0 with a new drive. I find it odd that zfs needed to resilver the drive after the reboot. Shouldn't the resilvered information be kept across reboots? Thanks Karl On 04/15/2011 03:55 PM, Cindy Swearingen wrote: Yes, the Solaris 10 9/10 release has the fix for RAIDZ checksum errors if you have ruled out any hardware problems. cs On 04/15/11 14:47, Karl Rossing wrote: Would moving the pool to a Solaris 10U9 server fix the random RAIDZ errors? On 04/15/2011 02:23 PM, Cindy Swearingen wrote: D'oh. One more thing. We had a problem in b120-123 that caused random checksum errors on RAIDZ configs. This info is still in the ZFS troubleshooting guide. See if a zpool clear resolves these errors. If that works, then I would upgrade to a more recent build and see if the problem is resolved completely. If not, then see the recommendation below. Thanks, Cindy On 04/15/11 13:18, Cindy Swearingen wrote: Hi Karl... I just saw this same condition on another list. I think the poster resolved it by replacing the HBA. Drives go bad but they generally don't all go bad at once, so I would suspect some common denominator like the HBA/controller, cables, and so on. See what FMA thinks by running fmdump like this: # fmdump TIME UUID SUNW-MSG-ID Apr 11 16:02:38.2262 ed0bdffe-3cf9-6f46-f20c-99e2b9a6f1cb ZFS-8000-D3 Apr 11 16:22:23.8401 d4157e2f-c46d-c1e9-c05b-f2d3e57f3893 ZFS-8000-D3 Apr 14 15:55:26.1918 71bd0b08-60c2-e114-e1bc-daa03d7b163f ZFS-8000-D3 This output will tell you when the problem started. Depending on what fmdump says, which probably indicates multiple drive problems, I would run diagnostics on the HBA or get it replaced. Always have good backups. Thanks, Cindy On 04/15/11 12:52, Karl Rossing wrote: Hi, One of our zfs volumes seems to be having some errors. So I ran zpool scrub and it's currently showing the following. -bash-3.2$ pfexec /usr/sbin/zpool status -x pool: vdipool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub in progress for 3h10m, 13.53% done, 20h16m to go config: NAME STATE READ WRITE CKSUM vdipool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 c9t14d0 ONLINE 0 012 6K repaired c9t15d0 ONLINE 0 013 167K repaired c9t16d0 ONLINE 0 011 5.50K repaired c9t17d0 ONLINE 0 020 10K repaired c9t18d0 ONLINE 0 015 7.50K repaired spares c9t19d0AVAIL errors: No known data errors I have another server connected to the same jbod using drives c8t1d0 to c8t13d0 and it doesn't seem to have any errors. I'm wondering how it could have gotten so screwed up? Karl CONFIDENTIALITY NOTICE: This communication (including all attachments) is confidential and is intended for the use of the named addressee(s) only and may contain information that is private, confidential, privileged, and exempt from disclosure under law. All rights to privilege are expressly claimed and reserved and are not waived. Any use, dissemination, distribution, copying or disclosure of this message and any attachments, in whole or in part, by anyone other than the intended recipient(s) is strictly prohibited. If you have received this communication in error, please notify the sender immediately, delete this communication from all data storage devices and destroy all hard copies. ___
Re: [zfs-discuss] zpool scrub on b123
> I'm going to replace c9t15d0 with a new drive. > > I find it odd that zfs needed to resilver the drive after the reboot. > Shouldn't the resilvered information be kept across reboots? the iostat data, as returned from iostat -en, are not kept over a reboot. I don't know if it's possible to keep them in zfs or otherwise. Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool scrub on b123
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Karl Rossing > > So i figured out after a couple of scrubs and fmadm faulty that drive > c9t15d0 was bad. > > My pool now looks like this: > NAME STATE READ WRITE CKSUM > vdipoolDEGRADED 0 0 2 >raidz1 DEGRADED 0 0 4 > c9t14d0ONLINE 0 0 1 512 resilvered > spare DEGRADED 0 0 0 >c9t15d0 OFFLINE 0 0 0 >c9t19d0 ONLINE 0 0 0 16.1G resilvered > c9t16d0ONLINE 0 0 1 512 resilvered > c9t17d0ONLINE 0 0 5 2.50K resilvered > c9t18d0ONLINE 0 0 1 512 resilvered > spares >c9t19d0 INUSE currently in use Um... Call me crazy, but ... If c9t15d0 was bad, then why do all those other disks have checksum errors on them? Although what you said is distinctly possible (faulty disk behaves so badly that it causes all the components around it to also exhibit failures), it seems unlikely. It seems much more likely that a common component (hba, ram, etc) is faulty, which could possibly be in addition to c9t15d0. Another possibility is that the faulty hba (or whatever) caused a false positive on c9t15d0. Maybe c9t15d0 isn't any more unhealthy than all the other drives on that bus, which may all be bad, or they may all be good including c9t15d0. (It wouldn't be the first time I've seen a whole batch of disks be bad, from the same mfgr with closely related serial numbers and mfgr dates.) I think you have to explain the checksum errors on all the other disks before drawing any conclusions. And the fact that it resilvered immediately after it resilvered... Only lends more credence to my suspicion in your bad-disk-diagnosis. BTW, what OS and what hardware are you running? How long has it been running, and how much attention do you give it? That is - Can you confidently say it was running without errors for 6 months and then suddenly started exhibiting this behavior? If this is in fact a new system, or if you haven't been paying much attention, I would not be surprised to see this type of behavior if you're running on unsupported or generic hardware. And when I say "unsupported" or "generic" I mean ... Intel, Asus, Dell, HP, etc, big name brands count as "unsupported" and "generic." Basically anything other than sun hardware and software fully updated and still in support contract, if I'm exaggerating to the extreme. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss