#49 — zpool import slow because of /dev/fd0

if someone knows a POSIX way to distinguish the two... we might

However, one splendid use case is ZFS on USB sticks.
We don't want to accidentally disable that option.

Moreover, (assuming GNU coreutils:)


     mkdir -pv /dev/rdsk
     ln -sv /dev/sd[abcdefghijkl]* /dev/rdsk/

     zpool import -d /dev/rdsk mypool

Will get you the result you wanted.


Otherwise, we could leave it to our friendly packaging volunteers, as they could simply apply their distro's mechanism (lshw, hal, udev, whatnot) to get the desired info. This could then be used in the init script for the distro to avoid lengthy waits

Ah I just saw: it cannot be valid. Of course, the minimum vdev size is (currently) 64Mb

If we could fidget out some IOCTL to get the size of the blockdevice before having to access it... That could work well

I think it's a legitimate approach to leave the "final polish" to packagers. Then, there is also a rationale for stuff to "just work" intelligently out of the box (there is much emphasis on it in Sun's original marketing of ZFS), even though people don't really appreciate the absence of glitches that they never encounter. ;-) So it's partly a matter of philosophy, and partly of "economics". Given that there are more important features to focus on (performance!), I'd consider it a low priority nice-to-have feature request. The danger of someone naming his USB stick /dev/fd0 exists, but then, wouldn't it be asking for trouble?

OK, simply filtering fd0 is the brutally pragmatic approach :) It is so simple that I missed it :)

I was thinking along the lines of detecting which block devices are suitable (by way of device(MAJ,MIN) numbers, IOCTL or stat-able properties).
This avoids depending on distro-specifics like udev, hal, dbus and whatnot.

A quick strace revealed:

sehe@karmic:~$ LANG=C sudo -E strace blockdev --getsize64 /dev/sda 2>&1 | tail
brk(0) = 0x8b8e000
brk(0x8baf000) = 0x8baf000
open("/dev/sda", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, BLKGETSIZE64, 0xbfe81928) = 0
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb784f000
close(3) = 0
write(1, "64023257088\n", 1264023257088
) = 12
exit_group(0) = ?

Seems to me that is entirely feasible. Can you confirm that we can probe the floppy for this IOCTL without incurring the delay? If so, we have a quick fix.
$0.02

I'm for it, as it would solve the fd0 problem elegantly. Not sure whether /dev/disk is available in all environments, though? It could always fall back on /dev, though.