[4875] in linux-scsi channel archive
Re: 2K sectors
daemon@ATHENA.MIT.EDU (Harvey Fishman)
Tue Oct 13 15:34:43 1998
Date: Tue, 13 Oct 1998 11:31:28 -0400 (EDT)
From: Harvey Fishman <fishman@panix.com>
To: Eric Youngdale <eric@andante.jic.com>
cc: William Brioschi <capo@writeme.com>,
Linux SCSI mailing list <linux-scsi@vger.rutgers.edu>
In-Reply-To: <Pine.LNX.3.96.981012222042.9681A-100000@andante.jic.com>
On Mon, 12 Oct 1998, Eric Youngdale wrote:
>
> On Thu, 8 Oct 1998, William Brioschi wrote:
>
> > I have a 640M magneto-optical drive which uses 2K blocks.
> > Of course, Linux (2.0.29) complains about the unsupported sector size.
> >
> > I _have_ to use it, mainly for backup purposes. Performance is not an issue:
> > I would be happy with a 100K/sec.
> >
> > I think there are three possibilities to be able to access a cartdridge:
> > 1) make Linux scsi disk and low level drivers digest the big sectors; this is
> > probably not a very good idea, unless it's already been done in a newer
> > kernel... has it?
>
> In the 2.1 series kernel, the disk and low-level drivers should
> already (in theory) handle this case. I don't have such a disk, so I
> have no way of verifying it myself (I could contrive a way to test it if
> need be).
>
> That being said, it is more than the disk driver that needs to
> grok the larger blocksize. Each filesystem needs to be able to tolerate
> it as well. Finally, the filesystem itself needs to be created with a
> blocksize >= the hardware sectorsize.
>
> The reactions that I have gotten from people are that for
> something like ext2, it works fine. With the msdos filesystem (in some
> flavor or another) it doesn't - I passed this comment along to the person
> who was maintaining that code in the hope that we find the problem.
I had already replied to this thread that I had had difficulties with mount
and the 2K sectors and then someone said that once you told mke2fs to use
the 2k sectors with a -b 2048 switch it would work. I tried that and sure
enough it did. I had never tried it with any file systems other than ext2,
but with FAT you would definitely need blocking/deblocking code in the
drivers as the design of the filesystem depends upon 512 byte logical
allocation units. Will work fine with other size physicals, but you must
explicitly do the mapping. As an aside, NT seems to have that code builtin
as I have no trouble with either FAT or NTFS (which also depends upon a 512
byte logical allocation unit) file systems there. I think that I did once
try the Linux NTFS driver with a 640 MB disk written under NT and as I
fuzzily remember it did not work, but the memories are not at all clear.
[snip]
> > 3) use the device in raw, sequential mode (through tar or something like that),
> > probably using the SCSI generic driver; I haven't tried this yet, is it
> > possible? should I do something particular or can I simply do a
> > "tar cf /dev/sga"?
>
> This absolutely won't work. The generics driver simply doesn't
> work like this.
Perhaps I do not understand what you are saying but I have never had any
real trouble using tar to write directly to the disk without a file system.
As I remember, the messages that are returned are rather equivocal and may
lead you to believe that it is not working, but if you let it run to
completion and then look at what seems to be written on the disk all of the
600+ MB of data seems to have gotten there and is straightforwardly
retrievable. I tried doing both a tar tvfc and actually retrieving a file
out near the end to be sure. Seemed to work fine.
Harvey
----------------------------------------------------------------------------
Harvey Fishman |
fishman@panix.com | A little heresy is good for the soul.
718-258-7276 |
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
