Hello,
There is a problem with the ZIP driver that follows me for quite a
longer time now. I can't exactly tell if it's the ZIP driver or an devfs
or an scsi emulation problem but I try to describe the problemcase as
good as possible.
I have an ATAPI Zip drive which I run through the SCSI emulation mode on
2.4/2.6 for quite some time now and my devs entries are being created
with devfs and devfsd which I'm running successfully for a couple of
years now.
Around 1 year or so, something has changed and finally today I found the
time writing about it.
The problem is that when having Linux booted and placing a Zip disk into
the drive then mounting doesn't work. It tells me that the device
doesn't exist. But the drive was found during boot.
So far so good on early 2.4 you simply cd into /dev/scsi.../.../ made an
'ls' and voila it gave the device a kick and it created the entry for
the Zip disk you then can mount it (devfs).
For 2.5 this doesn't work anymore and whenever you want to mount a Zip
disk you need to boot Linux together with a Disk inside the Drive, so
during boot it detects the Zip drive + the Disk.
But this behaviour is not correct because this opens the points:
a) I run my ATAPI CD-Rom in SCSI mode as well and it doesn't require a
media loaded during bootup. I can put a CD in whenever I want enter
mount /cdrom and voila it realizes the CD and mounts it. The CD-Rom is
being detected on boot nicely.
b) The same I do expect for Zip. It's being detected during boot but
somehow doesn't allow to mount if the linux kernel wasn't booted with a
Zip disk in the drive. But it shouldn't do that. I should be able to
boot linux normally, the drive get's detected and put a disk in it
whenever I wish.
I hope you can follow me.
For further feedback please CC me because I am not subscribed to the
list.
> The problem is that when having Linux booted and placing a Zip disk into
> the drive then mounting doesn't work. It tells me that the device
> doesn't exist. But the drive was found during boot
>
> So far so good on early 2.4 you simply cd into /dev/scsi.../.../ made an
> 'ls' and voila it gave the device a kick and it created the entry for
> the Zip disk you then can mount it (devfs).
>
> For 2.5 this doesn't work anymore and whenever you want to mount a Zip
> disk you need to boot Linux together with a Disk inside the Drive, so
> during boot it detects the Zip drive + the Disk.
yes devfs was castrated in 2.6 and removable media revalidation has been
removed without providing any suitable replacement.
If you use devfsd and uncomment these lines in devfsd.conf
# If you have removable media and want to force media revalidation when
looking
# up new or old compatibility names, uncomment the following lines
# SCSI NEWCOMPAT /dev/sd/* names
LOOKUP ^(sd/c[0-9]+b[0-9]+t[0-9]+u[0-9]+)p[0-9]+$ EXECUTE
/bin/dd if=$mntpnt/\1 of=/dev/null count=1
# SCSI OLDCOMPAT /dev/sd?? names
LOOKUP ^(sd[a-z]+)[0-9]+$ EXECUTE /bin/dd if=$mntpnt/\1
of=/dev/null count=1
# IDE NEWCOMPAT /dev/ide/hd/* names
LOOKUP ^(ide/hd/c[0-9]+b[0-9]+t[0-9]+u[0-9]+)p[0-9]+$ EXECUTE
/bin/dd if=$mntpnt/\1 of=/dev/null count=1
# IDE OLDCOMPAT /dev/hd?? names
LOOKUP ^(hd[a-z])[0-9]+$ EXECUTE /bin/dd if=$mntpnt/\1
of=/dev/null count=1
devfsd will attempt media revalidation on access to /dev/sdaN; if you are
using canonical devfs names you may add something similar to the above, e.g.
LOOKUP (scsi/.*)/part[0-9]+ EXECUTE /bin/dd if=$mntpnt/$1/disc of=/dev/null
count=1
this should revalidate media on access to partition. But you won't get
partition list on simple ls as in 2.4.
-andrey
On Sun, 2003-08-31 at 19:17, Andrey Borzenkov wrote:
> > For 2.5 this doesn't work anymore and whenever you want to mount a Zip
> > disk you need to boot Linux together with a Disk inside the Drive, so
> > during boot it detects the Zip drive + the Disk.
>
> yes devfs was castrated in 2.6 and removable media revalidation has been
> removed without providing any suitable replacement.
Ahh, thanks for letting me know this.
But this leads to the question why CD-ROM removable media revalidation
works. I mean let's see an SCSI CD-ROM, an ATAPI CD-ROM (in SCSI mode)
and ATAPI Zip (in SCSI mode) as *the same*.
They all have a host device (the mechanics itself), they all talk
through the same interface (straight SCSI or SCSI emulation). But CD-ROM
removable media revalidation works. E.g. I plug a CD in and it does the
trick, the Zip should be alike in my opinion. How does a Zip as
removable media differ from a CD for example.
By the way it would be pretty nice to improve devfs in this case. I also
heard a while back that it will be re-written anyways. Would be cool to
have a native support for that (Kernel related solution).
greetings,
A. A.
On Sunday 31 August 2003 21:55, Ali Akcaagac wrote:
> On Sun, 2003-08-31 at 19:17, Andrey Borzenkov wrote:
> > > For 2.5 this doesn't work anymore and whenever you want to mount a Zip
> > > disk you need to boot Linux together with a Disk inside the Drive, so
> > > during boot it detects the Zip drive + the Disk.
> >
> > yes devfs was castrated in 2.6 and removable media revalidation has been
> > removed without providing any suitable replacement.
>
> Ahh, thanks for letting me know this.
>
> But this leads to the question why CD-ROM removable media revalidation
> works. I mean let's see an SCSI CD-ROM, an ATAPI CD-ROM (in SCSI mode)
> and ATAPI Zip (in SCSI mode) as *the same*.
>
CD-ROM is not partitioned device, Zip is. You always have handle for the whole
disk (/dev/scsi/.../disc) - if not please let me know it is a bug. But
partitions are registered only when something is forcing media revalidation
i.e. attempts to access device. Just listing the devfs directory does not
count as access now.
> They all have a host device (the mechanics itself), they all talk
> through the same interface (straight SCSI or SCSI emulation). But CD-ROM
> removable media revalidation works. E.g. I plug a CD in and it does the
> trick, the Zip should be alike in my opinion. How does a Zip as
> removable media differ from a CD for example.
>
> By the way it would be pretty nice to improve devfs in this case. I also
> heard a while back that it will be re-written anyways. Would be cool to
> have a native support for that (Kernel related solution).
>
well ... it was not me who removed this code ...