Le Thu, 28 Jan 2016 19:31:10 +0200
"Kai Mäkisara (Kolumbus)" <kai.makisara@xxxxxxxxxxx> écrivait:
> > On 27.1.2016, at 1.35, Seymour, Shane M <shane.seymour@xxxxxxx>
> > wrote:
> >
> > Hi Emmanuel,
> >
> >> Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2
> >> PB which leaves some time to think about it, until LTO-15 circa
> >> 2036 :)
> >
> > There will be other issues to solve before then (by LTO-9 2 with
> > compression or LTO-10 without compression and we're at LTO-7 now).
> > Take tar format archives with a standard block size of 10k can take
> > this much data to get to 2^32 blocks and cause the current 32bit
> > block number to wrap:
> >
> > 43,980,465,111,040 (2^32 * 10240)
> >
> This is a somewhat theoretic example. In the 1990s no reasonable
> person used block size below 32 kB. Now the limit is probably higher.
> But, eventually we have to enlarge the block position and count
> variables.
You'd be surprised. In fact current LTO drive performance maxes out
between 32k and 256k. Most people would use 64k. Default for LTFS is
512k. Many, many people just use tar with the default block size, not
knowing any better (yay, shoeshine).
> > That's probably the correct time to also look at adding support for
> > more partitions. Not sure when the extended block id form of READ
> > POSITION got added but it may mean only supporting the wider values
> > only with tape drives that support REPORT SUPPORTED OPCODES (if
> > that can indicate that it supports READ POSITION with extended
> > block ids and anything else required to support block numbers
> > larger than 2^32).
> The current driver supports using up to ST_NBR_PARTITIONS (in the
> source set to 4). Support for using partitions must be in the driver.
> I am still not sure if partitioning the tape should be in the driver.
As a "normal" user, I pretty much don't want to ever have to look at
these atrocious SCSI reference docs :) So I'm all for as many things as
possible to be exposed through the driver instead. I'm pretty confident
that I'm expressing the ordinary developer/admin point of view here :)
> > The 0x91 version of SPACE needs to be used as well (the 32bit
> > version 0x11 Is currently used) to allow tape movement with counts
> > >2^32. That requires a new ioctl call. I haven't looked at what
> > >else may need to change but there's
> > likely to be more. The alternate version of SPACE is from page 220
> > of the above HP LTO5 tape reference.
> >
> The first step is to make the internal counters 64 bits. Then the
> code should be changed so that it can handle the large addresses.
> Note that this is necessary for handling partition changes even if no
> positioning commands are exposed to the user. The last step is to
> introduce the new positioning methods.
>
> The new positioning methods should perhaps be defined so that both
> the partition number and the block number are specified together. A
> proper tape address needs both.
>
Sounds good.
> But I think we should first fix the existing partitioning command so
> that it works for current drives.
Definitely :)
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@xxxxxxxxxxxxxx>
| +33 1 78 94 84 02
------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
