Is it possible to support a sector size 8192
Hi everybody,
i'm trying to access UDO/WORM mediums (which have a sector size of 8192) via a Plasmon UDO drive, but all I get is "unsupported sector size 8192" when I try to access it via /dev/sdX. drivers/scsi/sd.c suggests that the maximum sector size currently supported by Linux is 4096.
How difficult will it get to support 8192? Maybe we can pay somebody for doing it? (Kernel 2.4.21, RHEL 3.1).
Cheers, Johann
Quoted 10 lines · Johann
Hi everybody,
i'm trying to access UDO/WORM mediums (which have a sector size of 8192) via a Plasmon UDO drive, but all I get is "unsupported sector size 8192" when I try to access it via
/dev/sdX.drivers/scsi/sd.csuggests that the maximum sector size currently supported by Linux is 4096.How difficult will it get to support 8192? Maybe we can pay somebody for doing it? (Kernel 2.4.21, RHEL 3.1).
We (at Plasmon) investigated adding support in the kernel, but gave up quickly as it looked like it would need a huge amount of work in multiple areas. Instead, we've started shipping a userland filesystem driver for UDO based on FUSE. If you'd be interested in that, let me know...
Signature · 2 lines
Steve McIntyre, Cambridge, UK. [email protected] "Because heaters aren't purple!" -- Catherine Pitt
Quoted 9 lines · Steve McIntyre
Quoted 8 lines · Johann
Hi everybody,
i'm trying to access UDO/WORM mediums (which have a sector size of 8192) via a Plasmon UDO drive, but all I get is "unsupported sector size 8192" when I try to access it via
/dev/sdX.drivers/scsi/sd.csuggests that the maximum sector size currently supported by Linux is 4096.
Quoted 8 lines
Quoted 2 lines
How difficult will it get to support 8192? Maybe we can pay somebody for doing it? (Kernel 2.4.21, RHEL 3.1).
We (at Plasmon) investigated adding support in the kernel, but gave up quickly as it looked like it would need a huge amount of work in multiple areas. Instead, we've started shipping a userland filesystem driver for UDO based on FUSE. If you'd be interested in that, let me know...
Wouldn't it be possible to translate the sector size 2:1? For me, it doesn't seem that hard to do. But then again, I usually program other things than the kernel :)
Signature · 2 lines
Regards, Christian Iversen
Quoted 2 lines
we've started shipping a userland filesystem
driver for UDO based on FUSE.
How does the userland filesystem driver talk to the device?
It talks to it via /dev/sg*, i.e.
mount -t udo /dev/sga /mnt/udo
Quoted 4 lines · Bryan Henderson
Quoted 2 lines
we've started shipping a userland filesystem
driver for UDO based on FUSE.How does the userland filesystem driver talk to the device?
Quoted 4 lines · Bryan Henderson
Quoted 2 lines
we've started shipping a userland filesystem
driver for UDO based on FUSE.How does the userland filesystem driver talk to the device?
Using sg. It works quite well...
Signature · 3 lines
Steve McIntyre, Cambridge, UK. [email protected] "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Wow, an answer directly from Plasmon, that's nice. :-)
I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on FUSE 1.4, is this current?!). It is nice for a standalone drive, but we use a SCSI robotic changer in conjunction with an HSM system (Legato DiskXtender 2.9) which needs some kind of direct access to the drive. It probes for /dev/nst*, but I guess /dev/sd* would also work.
I know this exact configuration is not officially supported, but I'm a bit dissapointed that the limiting factor seems to be the Linux kernel. If I don't find a solution, it will probably become a Solaris/SPARC solution next week. :-(
Cheers, Johann
Quoted 17 lines · Steve McIntyre
Quoted 10 lines · Johann
Hi everybody,
i'm trying to access UDO/WORM mediums (which have a sector size of 8192) via a Plasmon UDO drive, but all I get is "unsupported sector size 8192" when I try to access it via
/dev/sdX.drivers/scsi/sd.csuggests that the maximum sector size currently supported by Linux is 4096.How difficult will it get to support 8192? Maybe we can pay somebody for doing it? (Kernel 2.4.21, RHEL 3.1).
We (at Plasmon) investigated adding support in the kernel, but gave up quickly as it looked like it would need a huge amount of work in multiple areas. Instead, we've started shipping a userland filesystem driver for UDO based on FUSE. If you'd be interested in that, let me know...
Quoted 1 line · Johann
Wow, an answer directly from Plasmon, that's nice. :-)
On my own time at the weekend, but I like to help... :-)
Quoted 2 lines
I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on FUSE 1.4, is this current?!).
That's the latest release, yes. We're working on a new release at the moment.
Quoted 4 lines
It is nice for a standalone drive, but we use a SCSI robotic changer in conjunction with an HSM system (Legato DiskXtender 2.9) which needs some kind of direct access to the drive. It probes for
/dev/nst*, but I guess/dev/sd*would also work.
Ah, OK.
Quoted 4 lines
I know this exact configuration is not officially supported, but I'm a bit dissapointed that the limiting factor seems to be the Linux kernel. If I don't find a solution, it will probably become a Solaris/SPARC solution next week. :-(
:-( The problem (for us) is the hardware page size on i386. On an architecture with a larger native page size (e.g. Alpha, sparc64), I'd expect you'd be able to simply patch the sd driver to allow 8KB support. A naive early attempt to do exactly that on i386 showed up page size issues in the VM/block layer underneath, and we left it alone at that point.
Signature · 5 lines
Steve McIntyre, Cambridge, UK. [email protected] Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
In article <[email protected]>,
Quoted 8 lines · Johann Hanne
Wow, an answer directly from Plasmon, that's nice. :-)
I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on FUSE 1.4, is this current?!). It is nice for a standalone drive, but we use a SCSI robotic changer in conjunction with an HSM system (Legato DiskXtender 2.9) which needs some kind of direct access to the drive. It probes for
/dev/nst*, but I guess/dev/sd*would also work.
I'm a little confused here. Tape devices have variable sector sizes. I believe they're required to handle up to 64K in a unix environment. The drives I work on go up to 256k.
Jay
Signature · 4 lines
* Jay Denebeim Moderator rec.arts.sf.tv.babylon5.moderated * * newsgroup submission address: [email protected] * * moderator contact address: [email protected] * * personal contact address: [email protected] *
Quoted 11 lines · Jay Denebeim
In article <[email protected]>,
Quoted 8 lines · Johann Hanne
Wow, an answer directly from Plasmon, that's nice. :-)
I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on FUSE 1.4, is this current?!). It is nice for a standalone drive, but we use a SCSI robotic changer in conjunction with an HSM system (Legato DiskXtender 2.9) which needs some kind of direct access to the drive. It probes for
/dev/nst*, but I guess/dev/sd*would also work.
Quoted 3 lines
I'm a little confused here. Tape devices have variable sector sizes. I believe they're required to handle up to 64K in a unix environment. The drives I work on go up to 256k.
Tapes are different. The UDO drive that Johann was asking about is an optical _disk_ drive...
Signature · 2 lines
Steve McIntyre, Cambridge, UK. [email protected] Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
Quoted 8 lines · Steve McIntyre
Quoted 7 lines · Jay Denebeim
Quoted 6 lines
I've already got the FUSE driver (udofs-1.1-92.i386.rpm, based on FUSE 1.4, is this current?!). It is nice for a standalone drive, but we use a SCSI robotic changer in conjunction with an HSM system (Legato DiskXtender 2.9) which needs some kind of direct access to the drive. It probes for
/dev/nst*, but I guess/dev/sd*would also work.
Quoted 6 lines
Quoted 3 lines
I'm a little confused here. Tape devices have variable sector sizes. I believe they're required to handle up to 64K in a unix environment. The drives I work on go up to 256k.
Tapes are different. The UDO drive that Johann was asking about is an optical _disk_ drive...
Yeah, I got that. I wasn't going to say anything until he mentioned using the tape driver with it. Is the UDO drive presenting itself as a tape or as a disk?
Jay
Signature · 4 lines
* Jay Denebeim Moderator rec.arts.sf.tv.babylon5.moderated * * newsgroup submission address: [email protected] * * moderator contact address: [email protected] * * personal contact address: [email protected] *
Quoted 8 lines · Jay Denebeim
Quoted 6 lines · Steve McIntyre
Quoted 4 lines · Jay Denebeim
I'm a little confused here. Tape devices have variable sector sizes. I believe they're required to handle up to 64K in a unix environment. The drives I work on go up to 256k.
Quoted 6 lines
Quoted 2 lines
Tapes are different. The UDO drive that Johann was asking about is an optical _disk_ drive...
Yeah, I got that. I wasn't going to say anything until he mentioned using the tape driver with it. Is the UDO drive presenting itself as a tape or as a disk?
It's a disk, SCSI type 7 (optical). The tape thing is a red herring, IMHO.
Signature · 4 lines
Steve McIntyre, Cambridge, UK. [email protected] You lock the door And throw away the key There's someone in my head but it's not me
Quoted 5 lines
Quoted 3 lines
I'm a little confused here. Tape devices have variable sector sizes. I believe they're required to handle up to 64K in a unix environment. The drives I work on go up to 256k.
Tapes are different. The UDO drive that Johann was asking about is an optical _disk_ drive...
Hmm... would it be _possible_ to support it as tape device (/dev/st* and /dev/nst*)?
Cheers, Johann
In article <[email protected]> you write:
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
I'm a little confused here. Tape devices have variable sector sizes. I believe they're required to handle up to 64K in a unix environment. The drives I work on go up to 256k.
Tapes are different. The UDO drive that Johann was asking about is an optical _disk_ drive...
Hmm... would it be _possible_ to support it as tape device (
/dev/st*and/dev/nst*)?
Not that I'm aware, no. It's not designed to be used as a tape at all. To be honest, if you want a device that looks like a tape, then... :-)
Signature · 3 lines
Steve McIntyre, Cambridge, UK. [email protected] Into the distance, a ribbon of black Stretched to the point of no turning back