Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#19 rmt: Fix for detecting end-of-tape for solaris compatability

open
nobody
None
5
2011-11-04
2011-11-04
Anonymous
No

The Solaris ufsdump program seems to detect end-of-tape strictly by seeing a successful write to tape reporting less than the requested amount of data written. For example, it requests to write 64b, and rmt reports that 32b were written successfully (like A32) instead of reporting an error.

Linux rmt uses write() which only reports success or error. There does not appear to be the ability to report a partial write when end of tape is seen in the scsi driver as that causes write to report an error (ENOSPC) on the next write.

So I made this quick and dirty fix that will return 'A0' rather than error when a write fails with ENOSPC. This works great on Solaris ufsdump. I'm not sure if it will cause problems with Linux dump though.

For reference, testing was done with Solaris 10 and RHEL 3. Even though RHEL 3 is very old, even the current dump source has the same code which I fully suspect would cause the same behavior on a newer OS/kernel.

Discussion


  • Anonymous
    2011-11-04

    rmt ENOSPC patch

     
    Attachments

  • Anonymous
    2011-11-04

    For clarification on my comment about write(), this is more specifically what I believe is happening:

    My tape drives (HP LTO2) and probably most modern drives have large asynchronous buffers and lots of space beyond the EoM marker. This means that when the EoM early warning occurs, in-flight writes will (always?) be completed 100%. Thus no partial write is reported to rmt, and thus back to ufsdump. The next write to the drive will then fail with ENOSPC as one would expect. But, since write() errors, rmt passes that error back to ufsdump, which sees it as a failure condition and bombs out.

    Even though I said 'quick and dirty,' I think the logic is pretty sound. ENOSPC is a not really a problem as much as a condition. Reporting it as a successful write but with 0 bytes written seems reasonable.

    It does not appear that returning A0 would harm Linux dump. I see that the dump source already interprets ENOSPC error as EoT anyways. That makes perfect sense. Unfortunately, Solaris' ufsdump is not as smart.

     
    Last edit: Anonymous 2013-10-20