Manoj Joseph wrote:
Manoj Joseph wrote:
Hi,
In brief, what I am trying to do is to use libzpool to access a zpool
- like ztest does.
[snip]
No, AFAIK, the pool is not damaged. But yes, it looks like the device
can't be written to by the userland zfs.
Well, I might have figured out something.
Turssing the process shows this:
/1: open64("/dev/rdsk/c2t0d0s0", O_RDWR|O_LARGEFILE) = 3
/108: pwrite64(3, " X0101\0140104\n $\0\r ".., 638, 4198400) Err#22
EINVAL
/108: pwrite64(3, "FC BFC BFC BFC BFC BFC B".., 386, 4199038) Err#22
EINVAL
[more failures...]
The writes are not aligned to a block boundary. And, apparantly, unlike
files, this does not work for devices.
Question: were ztest and libzpool not meant to be run on real devices?
Or could there be an issue in how I setup up things?
The failing write has this call stack:
pwrite64:return
libc.so.1`_pwrite64+0x15
libzpool.so.1`vn_rdwr+0x5b
libzpool.so.1`vdev_file_io_start+0x17e
libzpool.so.1`vdev_io_start+0x18
libzpool.so.1`zio_vdev_io_start+0x33d
[snip]
usr/src/uts/common/fs/zfs/vdev_file.c has this:
/*
* From userland we access disks just like files.
*/
#ifndef _KERNEL
vdev_ops_t vdev_disk_ops = {
vdev_file_open,
vdev_file_close,
vdev_default_asize,
vdev_file_io_start,
vdev_file_io_done,
NULL,
VDEV_TYPE_DISK, /* name of this vdev type */
B_TRUE /* leaf vdev */
};
Guess vdev_file_io_start() does not work very well for devices.
Regards,
Manoj
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
