[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 stdio.h
#include string.h
#include fcntl.h
#include sys/stat.h
#include sys/types.h
#include unistd.h
#include errno.h
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 stdio.h
#include string.h
#include fcntl.h
#include sys/stat.h
#include sys/types.h
#include unistd.h
#include errno.h
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 stdio.h
#include string.h
#include fcntl.h
#include sys/stat.h
#include sys/types.h
#include unistd.h
#include errno.h
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 jeff@oracle.com 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 size 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 OS device name Regards, Bing On 04/17/11 16:55, Tuomas Leikola wrote: Hei, I'm crossposting this to zfs as i'm not sure which bit is to blame here. I've been having this issue that i cannot really fix myself: I have a OI 148 server, which hosts a log of disks on SATA controllers. Now it's full and needs some data moving work to be done, so i've acquired another box which runs linux and has several sata enclosures. I'm using solaris iscsi on static-config to connect the device. Normally, when everything is fine, no problems. I can even restart the iet daemon and theres just a short hiccup in the IO-stream. Things go bad when i turn the iscsi target off for a longer period (reboot, etc). The solaris iscsi times out, and responds these as errors to zfs. zfs increases error counts (loses writes maybe) and eventually marks all devices as failed and the array halts (failmode=wait). When in this state, there is no luck returning to running state. The failed condition doesn't purge itself after the target becomes online again. I've tried zpool clear but it still reports data errors and devices as faulted. zpool export hangs. how i see this problem is that a) iscsi initiator reports timeouts as permanent b) zfs handles them as such c) there is no timeout never to be chosen as far as i can see What I would like is a mode equivalent to nfs hard mount - wait forever for the device to become available (but ability to kick the array from cmdline if it is really dead). Any clues? ___ 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?
在 2011-4-18，下午6:03， Joerg Schilling 写道：
jeff.liu jeff@oracle.com 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 size 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
