| From | Sent On | Attachments |
|---|---|---|
| Kern Sibbald | Jun 1, 2003 10:54 am | |
| Dan Langille | Jun 1, 2003 11:32 am | |
| Justin T. Gibbs | Jun 1, 2003 1:08 pm | |
| Kern Sibbald | Jun 1, 2003 2:44 pm | |
| Justin T. Gibbs | Jun 1, 2003 3:39 pm | |
| Matthew Jacob | Jun 1, 2003 5:00 pm | |
| Matthew Jacob | Jun 1, 2003 5:13 pm | |
| Dan Langille | Jun 1, 2003 6:58 pm | |
| Matthew Jacob | Jun 1, 2003 7:03 pm | |
| Kern Sibbald | Jun 2, 2003 1:28 am | |
| Kern Sibbald | Jun 2, 2003 1:29 am | |
| Kern Sibbald | Jun 2, 2003 1:57 am | |
| Kern Sibbald | Jun 2, 2003 3:45 am | |
| Dan Langille | Jun 2, 2003 4:28 am | |
| Matthew Jacob | Jun 2, 2003 8:05 am | |
| Justin T. Gibbs | Jun 2, 2003 8:10 am | |
| Dan Langille | Jun 2, 2003 8:14 am | |
| Matthew Jacob | Jun 2, 2003 8:21 am | |
| Kern Sibbald | Jun 2, 2003 8:27 am | |
| Dan Langille | Jun 2, 2003 9:46 am | |
| Dan Langille | Jun 2, 2003 11:05 am | |
| Matthew Jacob | Jun 2, 2003 11:11 am | |
| Justin T. Gibbs | Jun 2, 2003 11:49 am | |
| Dan Langille | Jun 2, 2003 12:06 pm | |
| Justin T. Gibbs | Jun 2, 2003 12:10 pm | |
| Matthew Jacob | Jun 2, 2003 1:14 pm | |
| Dan Langille | Jun 2, 2003 2:16 pm | |
| Matthew Jacob | Jun 2, 2003 2:24 pm | |
| Kern Sibbald | Jun 2, 2003 2:46 pm | |
| Matthew Jacob | Jun 2, 2003 2:55 pm | |
| Kern Sibbald | Jun 2, 2003 3:31 pm | |
| Carl Reisinger | Jun 2, 2003 3:44 pm | |
| Matthew Jacob | Jun 2, 2003 3:44 pm | |
| Dan Langille | Jun 2, 2003 6:37 pm | |
| Kern Sibbald | Jun 3, 2003 12:28 am | |
| Kern Sibbald | Jun 3, 2003 6:07 am | |
| Carl Reisinger | Jun 3, 2003 6:19 am | |
| Kern Sibbald | Jun 3, 2003 6:37 am | |
| Carl Reisinger | Jun 3, 2003 7:01 am | |
| Matthew Jacob | Jun 3, 2003 7:34 am | |
| Justin T. Gibbs | Jun 3, 2003 7:51 am | |
| Kern Sibbald | Jun 3, 2003 8:05 am | |
| Kern Sibbald | Jun 3, 2003 8:11 am | |
| Matthew Jacob | Jun 3, 2003 9:03 am | |
| Dan Langille | Jun 3, 2003 9:10 am | |
| Justin T. Gibbs | Jun 3, 2003 9:24 am | |
| Kern Sibbald | Jun 3, 2003 9:40 am | |
| Justin T. Gibbs | Jun 3, 2003 10:03 am | |
| Kern Sibbald | Jun 3, 2003 10:19 am | |
| Kern Sibbald | Jun 3, 2003 10:34 am | |
| Matthew Jacob | Jun 3, 2003 11:00 am | |
| Matthew Jacob | Jun 3, 2003 11:16 am | |
| Matthew Jacob | Jun 3, 2003 11:39 am | |
| Justin T. Gibbs | Jun 3, 2003 12:12 pm | |
| Dan Langille | Jun 3, 2003 12:43 pm | |
| Matthew Jacob | Jun 3, 2003 12:46 pm | |
| Kern Sibbald | Jun 3, 2003 1:05 pm | |
| PostMaster General | Jun 3, 2003 2:21 pm | |
| Kern Sibbald | Jun 4, 2003 12:20 am | |
| Matthew Jacob | Jun 4, 2003 7:51 am | |
| Kern Sibbald | Jun 4, 2003 9:51 am | |
| Kern Sibbald | Jun 6, 2003 7:38 am | |
| Dan Langille | Jun 6, 2003 8:59 am | |
| Matthew Jacob | Jun 6, 2003 11:50 am | |
| Dan Langille | Jun 20, 2003 6:17 pm | |
| Dan Langille | Jul 1, 2003 5:07 pm | |
| Matthew Jacob | Jul 1, 2003 11:11 pm | |
| Michael L. Squires | Aug 25, 2003 4:16 am | |
| Dan Langille | Aug 25, 2003 9:13 am | |
| Michael L. Squires | Aug 27, 2003 5:27 am |
| Subject: | SCSI tape data loss | |
|---|---|---|
| From: | Kern Sibbald (ke...@sibbald.com) | |
| Date: | Jun 3, 2003 6:37:28 am | |
| List: | org.freebsd.freebsd-scsi | |
Thanks for the lesson is how blocks are written to a tape -- especially the example. I'm now leaning strongly toward aligning my buffers. However a couple more questions please.
- When using tar (or say Bacula), how do you know your writes are split by the kernel? In the case of Bacula, with the buffer size I use, it ALWAYS gets back exactly what it wrote. From my userland perspective I see no double writes.
- What is the "page" that you are referring to? Paged memory? If I am not mistaken the page size can be radically different depending on the OS and hardware. I.e. 1024 to 4096 or even more.
- How does one determine what a page size is, preferably in a system independent way?
Thanks,
Kern
On Tue, 2003-06-03 at 15:19, Carl Reisinger wrote:
Concerning the maximum buffer size: I have chosen the default maximum buffer size to be 64512 bytes so that it is smaller than 65536. In fact, 64512 bytes is the size (126 blocks) that I used for tar in 1982 and never had any problems.
Try using the FreeBSD tar with the multi-volume flag (-M) and your record size.
Without the flag the writes are page aligned, with the flag the writes are offset some, either 512 or 1536 bytes (I forget which), and the writes will be split by the kernel physio function into a 60K and 3K write. (This is with the tar shipped with FreeBSD up to at least 4.2. Later ones may also do this, I have not tried them)
From what I understand the 65536 point at which buffers are always split only applies to devices in fixed block mode, and probably older devices at that.
This magic number has nothing to do with the device. I've only used variable block mode and newer technologies, SDLT, LTO.
Though Bacula can run in fixed block mode, the default is variable block, so I don't see that as an issue here -- unless I am missing something?
Can you explain why you mention 61440 bytes? and why it might be a better choice than 64512?
61440 was mentioned since that is the largest write that can be done without the physio function doing some surprising and annoying things to your write. 61440 is the size that, no matter its address alignment, can always be mapped with one page register.
If you are careful to page align all writes then you can write up to 65536 and have one record sent to the tape device.
(Actually, with a minor change to scsi_sa.c and limiting one self to newer SCSI HBAs you can go as high as 128KB for read/write)
An example:
Write 64512 bytes with a starting address of 4096. Physio will take this, see that the address is paged aligned, check that it can be mapped with one page register and perform one write.
Now lets write 64512 bytes but with an address of 5632. In this case physio will notice it is not paged aligned and adjust the starting address to be 4096. Now 66048 bytes need to be mapped which exceeds the default size of 65536. In this case physio will map the first 60K (64K to him because of the starting address change), write that and then map and write the remainder.
Now when one goes back to read 64512 bytes, the first read returns 61440 bytes and the second 3072 instead of just one read retuning 64512.
On aligning the buffers on a page boundary: interesting idea, I'll look into it, but I'm not too keen on the idea.
If your software has no problem with short reads and records being split into two, then don't bother page aligning. But, if you want to read exectly what you know you wrote then alignment is a must.
Carl





