On Mon, Dec 23, 2013 at 11:23:28AM +0100, J. Hannken-Illjes wrote:
> On Dec 23, 2013, at 11:15 AM, Emmanuel Dreyfus wrote:
>
> > On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote:
> >> In short: tape records bigger than MAXPHYS (most time 64k) don't work.
> >
> > Is it a NetBSD l
m...@netbsd.org (Emmanuel Dreyfus) writes:
>Ad since the MAXPHYS limit also exists on plain tape access (without
>LTFS), this means no modern LTO drive can be used at all on NetBSD until
>you merge your branch?
The drives should work assuming that you restrict yourself to
fixed block sizes <= MA
On Mon, Dec 23, 2013 at 03:04:06PM +, Emmanuel Dreyfus wrote:
> On Mon, Dec 23, 2013 at 09:57:10AM -0500, Thor Lancelot Simon wrote:
> > To be clear, using small blocks on modern tapes will probably lead to
> > a dramatic reduction in tape capacity, not just read and write speed.
> > Tapes can
On Mon, Dec 23, 2013 at 09:57:10AM -0500, Thor Lancelot Simon wrote:
> To be clear, using small blocks on modern tapes will probably lead to
> a dramatic reduction in tape capacity, not just read and write speed.
> Tapes can get very, very expensive, so a warning seemed to be in order!
Ad since th
On Mon, Dec 23, 2013 at 02:41:29PM +, Emmanuel Dreyfus wrote:
> On Mon, Dec 23, 2013 at 09:23:09AM -0500, Thor Lancelot Simon wrote:
> > > I adjusted the function that detects tape block size so that it is
> > > capped to MAXPHYS. I also fixed the debug message so that I get the
> > The result
On Mon, Dec 23, 2013 at 02:54:42PM +0100, J. Hannken-Illjes wrote:
> > LTFS20010D SCSI request: [ 08 02 01 00 00 00 ] Requested length=65536
> > LTFS20089D Driver detail:errno = 0x0
> > LTFS20089D Driver detail: status = 0x2
> > LTFS20089D Driver detail: retsts = 0x4
On Mon, Dec 23, 2013 at 09:23:09AM -0500, Thor Lancelot Simon wrote:
> > I adjusted the function that detects tape block size so that it is
> > capped to MAXPHYS. I also fixed the debug message so that I get the
> The resulting performance will leave much to be desired...
I can imagine that. But
On Mon, Dec 23, 2013 at 10:59:09AM +, Emmanuel Dreyfus wrote:
> On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote:
> > In short: tape records bigger than MAXPHYS (most time 64k) don't work.
>
> I adjusted the function that detects tape block size so that it is
> capped to MAXP
On Dec 23, 2013, at 3:00 PM, Emmanuel Dreyfus wrote:
> On Mon, Dec 23, 2013 at 02:54:42PM +0100, J. Hannken-Illjes wrote:
>> This is XS_SHORTSENSE (it also matches retsts being 0x04).
>>
>> It is an atapi drive?
>
> No, SAS through the mpii driver.
That doesn't make sense -- as far as I grep
On Mon, Dec 23, 2013 at 02:54:42PM +0100, J. Hannken-Illjes wrote:
> This is XS_SHORTSENSE (it also matches retsts being 0x04).
>
> It is an atapi drive?
No, SAS through the mpii driver.
> You try to read a record being larger than the buffer (65536)?
And it will not be able to return me the tr
On Dec 23, 2013, at 1:54 PM, m...@netbsd.org (Emmanuel Dreyfus) wrote:
> J. Hannken-Illjes wrote:
>
>> According to T10.ORG scsi commands a3/a4 for sequential devices are optional:
>>
>> OP DTLPWROMAEBKVF Description
>> A3 OOO O OOMOOOM MAINTENANCE IN
>> A4 OOO O OOO MAINTENANCE OUT
J. Hannken-Illjes wrote:
> According to T10.ORG scsi commands a3/a4 for sequential devices are optional:
>
> OP DTLPWROMAEBKVF Description
> A3 OOO O OOMOOOM MAINTENANCE IN
> A4 OOO O OOO MAINTENANCE OUT
>
> What are you trying to do here?
I am trying to mount a LTFS formatted tap
On Dec 23, 2013, at 11:59 AM, Emmanuel Dreyfus wrote:
> On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote:
>> In short: tape records bigger than MAXPHYS (most time 64k) don't work.
>
> I adjusted the function that detects tape block size so that it is
> capped to MAXPHYS. I also
On Dec 23, 2013, at 11:15 AM, Emmanuel Dreyfus wrote:
> On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote:
>> In short: tape records bigger than MAXPHYS (most time 64k) don't work.
>
> Is it a NetBSD limitation that should be fixed in NetBSD, or an non standard
> assumption from
On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote:
> In short: tape records bigger than MAXPHYS (most time 64k) don't work.
I adjusted the function that detects tape block size so that it is
capped to MAXPHYS. I also fixed the debug message so that I get the
scsireq_t NetBSD field
On Mon, Dec 23, 2013 at 11:11:10AM +0100, J. Hannken-Illjes wrote:
> In short: tape records bigger than MAXPHYS (most time 64k) don't work.
Is it a NetBSD limitation that should be fixed in NetBSD, or an non standard
assumption from LTFS that should be fixed in LTFS?
--
Emmanuel Dreyfus
m...@ne
On Dec 23, 2013, at 10:54 AM, Emmanuel Dreyfus wrote:
> Hi
>
> I am still working on porting LTFS to NetBSD. The thing now builds,
> and I am able to format a tape using the mkltfs utility.
>
> Next step is to mount the tape. It now fails within the NetBSD kernel.
>
> Here is ltfs output:
> L
Hi
I am still working on porting LTFS to NetBSD. The thing now builds,
and I am able to format a tape using the mkltfs utility.
Next step is to mount the tape. It now fails within the NetBSD kernel.
Here is ltfs output:
LTFS20039D Backend read: 524288 bytes
LTFS20010D SCSI request: [ 08 02 08 0
18 matches
Mail list logo
