[Stgt-devel] segfault in the ssc code ...

[Richard Sharpe]

On Sat, Jul 26, 2008 at 4:56 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> From: "Richard Sharpe" <realrichardsharpe at gmail.com>
> Subject: Re: [Stgt-devel] segfault in the ssc code ...
> Date: Sat, 26 Jul 2008 16:40:59 -0700

[trim, trim, trim ...]

>> >> I was wondering if this change would do the trick:
>> >>
>> >> In usr/smc.c, change set_slot_full to take a target structure as well
>> >> as the other args, and from that call tgt_set_device_path_update,
>> >> which will also call the correct things ...
>> >>
>> >> and in set_slot_empty, also call tdt_set_device_path_update ...
>> >
>> > When I put this bit into the code, I was thinking something like "exec
>> > tgtadm .... <with options to update backing store>"
>
> Agreed, I like that.

Why do you want to exec tgtadm again when this code is running in the
context of tgtd and is simply executing an SMC request to load a tape
into the drive.

Why not expose the correct method in target.c and have the code call it ...


>
>> > Where the backing store consists of a path prefix along with the 'barcode'
>> > as the filename.
>> >
>> > I'm sure there is a neater method however.
>
> What do you think about using extended attributes as Ronnie suggested?

Hmmm, that seems OK for things like file marks and setmarks

>> > The same thing is required for the MMC device as well (for a Virtual CD/DVD
>> > Library).
>>
>> Hmmm, while I have stuff mostly working, further examination showed
>> that I should have passed --params bstype=ssc or something like that
>> when I created the virtual tape drive, in which case I would get the
>> correct backing store module, I think ...

That seems to have done the trick. I am still checking.

BTW, the MAM implementation is wrong as well. It is not a per-drive
attribute, it is a per-cartridge attribute, and thus per-virtual-tape.

This too, could be stored in extended attributes, and retrieved when
the virtual tape is moved into a drive.