xfs
[Top] [All Lists]

Re: System locking: kernel-2.4.6pre3-xfs

To: Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: System locking: kernel-2.4.6pre3-xfs
From: Seth Mos <knuffie@xxxxxxxxx>
Date: Fri, 13 Jul 2001 07:32:21 +0200 (CEST)
Cc: Luc Lalonde <llalonde@xxxxxxxxxxxxxxx>, "linux-xfs@xxxxxxxxxxx" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20010713122920.K11622@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Fri, 13 Jul 2001, Timothy Shimmin wrote:

> Hi Luc,
> 
> On Thu, Jul 12, 2001 at 04:35:18PM +0200, Seth Mos wrote:
> > >I looked this morning and I see this message (dmesg):
> > >
> > >st0: Block limits 1 - 16777215 bytes
> > 
> > This equates to 15GB... rotten tape or drive going mad. It should read 20GB 
> > if I am correct.
> > If I use 1GB = 1000MB it comes at 16GB which is still 4GB short.
> Hmmm...sorry I don't understand this comment.
> 
> The message is coming from the scsi tape driver (linux/drivers/scsi/st.c)
> and I believe it is printed the first time the tape device is opened.
> It specifies the limits on the block size - thus the size of a read
> or write have to be within these limits.
> In xfsdump/xfsrestore we use a read/write size of 1Mb.
> We have tested with an Archive Python DAT drive and we always
> seem to get that exact message i.e. 16Mb for max. block size
> (it is the result of a READ_BLOCK_LIMITS scsi cmd).
> 
> So that msg looks normal to me :)

Nevermind this message, I'm blaming the windows calc ;-)
The coffee probably was not strong enough.

> (According to linux/drivers/scsi/README.st, you could define
>  DEBUG in st.c and have it generate debugging messages.
>  Don't know if this would help show anything useful though.)
> 
> --Tim
 


<Prev in Thread] Current Thread [Next in Thread>