Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-12-06 Thread Maurizio Lombardi



Dne 6.12.2018 v 11:34 Maurizio Lombardi napsal(a):
> This is what I see when a cd burn operation completes:
> 


This is the complete blktrace log:

 11,034 0.81759 11653  D   W 63488 (2a 00 00 03 3c 29 00 00 
1f 00 ..) [wodim]
 11,034 0.81759 11653  D   W 63488 (2a 00 00 03 3c 29 00 00 
1f 00 ..) [wodim]
 11,034 0.81759 11653  D   W 63488 (2a 00 00 03 3c 29 00 00 
1f 00 ..) [wodim]
 11,034 0.81759 11653  D   W 63488 (2a 00 00 03 3c 29 00 00 
1f 00 ..) [wodim]
 11,038 0.049744147 11653  D   W 63488 (2a 00 00 03 3c 48 00 00 
1f 00 ..) [wodim]
 11,038 0.049744147 11653  D   W 63488 (2a 00 00 03 3c 48 00 00 
1f 00 ..) [wodim]
 11,038 0.049744147 11653  D   W 63488 (2a 00 00 03 3c 48 00 00 
1f 00 ..) [wodim]
 11,038 0.049744147 11653  D   W 63488 (2a 00 00 03 3c 48 00 00 
1f 00 ..) [wodim]
 11,03   12 0.102512363 11653  D   W 63488 (2a 00 00 03 3c 67 00 00 
1f 00 ..) [wodim]
 11,03   12 0.102512363 11653  D   W 63488 (2a 00 00 03 3c 67 00 00 
1f 00 ..) [wodim]
 11,03   12 0.102512363 11653  D   W 63488 (2a 00 00 03 3c 67 00 00 
1f 00 ..) [wodim]
 11,03   12 0.102512363 11653  D   W 63488 (2a 00 00 03 3c 67 00 00 
1f 00 ..) [wodim]
 11,03   16 0.152219178 11653  D   W 63488 (2a 00 00 03 3c 86 00 00 
1f 00 ..) [wodim]
 11,03   16 0.152219178 11653  D   W 63488 (2a 00 00 03 3c 86 00 00 
1f 00 ..) [wodim]
 11,03   16 0.152219178 11653  D   W 63488 (2a 00 00 03 3c 86 00 00 
1f 00 ..) [wodim]
 11,03   16 0.152219178 11653  D   W 63488 (2a 00 00 03 3c 86 00 00 
1f 00 ..) [wodim]
 11,03   20 0.205093330 11653  D   W 63488 (2a 00 00 03 3c a5 00 00 
1f 00 ..) [wodim]
 11,03   20 0.205093330 11653  D   W 63488 (2a 00 00 03 3c a5 00 00 
1f 00 ..) [wodim]
 11,03   20 0.205093330 11653  D   W 63488 (2a 00 00 03 3c a5 00 00 
1f 00 ..) [wodim]
 11,03   20 0.205093330 11653  D   W 63488 (2a 00 00 03 3c a5 00 00 
1f 00 ..) [wodim]
 11,03   24 0.254684616 11653  D   W 63488 (2a 00 00 03 3c c4 00 00 
1f 00 ..) [wodim]
 11,03   24 0.254684616 11653  D   W 63488 (2a 00 00 03 3c c4 00 00 
1f 00 ..) [wodim]
 11,03   24 0.254684616 11653  D   W 63488 (2a 00 00 03 3c c4 00 00 
1f 00 ..) [wodim]
 11,03   24 0.254684616 11653  D   W 63488 (2a 00 00 03 3c c4 00 00 
1f 00 ..) [wodim]
 11,03   28 0.307478799 11653  D   W 63488 (2a 00 00 03 3c e3 00 00 
1f 00 ..) [wodim]
 11,03   28 0.307478799 11653  D   W 63488 (2a 00 00 03 3c e3 00 00 
1f 00 ..) [wodim]
 11,03   28 0.307478799 11653  D   W 63488 (2a 00 00 03 3c e3 00 00 
1f 00 ..) [wodim]
 11,03   28 0.307478799 11653  D   W 63488 (2a 00 00 03 3c e3 00 00 
1f 00 ..) [wodim]
 11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   36 0.409940696 11653  D   W 63488 (2a 00 00 03 3d 21 00 00 
1f 00 ..) [wodim]
 11,03   36 0.409940696 11653  D   W 63488 (2a 00 00 03 3d 21 00 00 
1f 00 ..) [wodim]
 11,03   36 0.409940696 11653  D   W 63488 (2a 00 00 03 3d 21 00 00 
1f 00 ..) [wodim]
 11,03   36 0.409940696 11653  D   W 63488 (2a 00 00 03 3d 21 00 00 
1f 00 ..) [wodim]
 11,03   40 0.459603865 11653  D   W 63488 (2a 00 00 03 3d 40 00 00 
1f 00 ..) [wodim]
 11,03   40 0.459603865 11653  D   W 63488 (2a 00 00 03 3d 40 00 00 
1f 00 ..) [wodim]
 11,03   40 0.459603865 11653  D   W 63488 (2a 00 00 03 3d 40 00 00 
1f 00 ..) [wodim]
 11,03   40 0.459603865 11653  D   W 63488 (2a 00 00 03 3d 40 00 00 
1f 00 ..) [wodim]
 11,03   44 0.512511601 11653  D   W 63488 (2a 00 00 03 3d 5f 00 00 
1f 00 ..) [wodim]
 11,03   44 0.512511601 11653  D   W 63488 (2a 00 00 03 3d 5f 00 00 
1f 00 ..) [wodim]
 11,03   44 0.512511601 11653  D   W 63488 (2a 00 00 03 3d 5f 00 00 
1f 00 ..) [wodim]
 11,03   44 0.512511601 11653  D   W 63488 (2a 00 00 03 3d 5f 00 00 
1f 00 ..) [wodim]
 11,03   48 0.562033003 11653  D   W 63488 (2a 00 00 03 3d 7e 00 00 
1f 00 ..) [wodim]
 11,03   48 0.562033003 11653  D   W 63488 (2a 00 00 03 3d 7e 00 00 
1f 00 ..) [wodim]
 11,03   48 0.562033003 11653  D   W 63488 (2a 00 00 03 3d 7e 00 00 
1f 00 ..) [wodim]
 11,03   48 0.562033003 11653  D   W 63488 (2a 00 00 03 3d 7e 00 00 
1f 00 ..) [wodim]
 11,03   52 0.614956620 11653  D   W 63488 (2a 00 00 03 3d 9d 00 00 
1f 00 ..) 

Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-12-06 Thread Maurizio Lombardi
Hi Jens,

Dne 20.6.2018 v 16:09 Jens Axboe napsal(a):
> On 6/20/18 5:52 AM, Maurizio Lombardi wrote:
>> Hi Jens,
>>
>> Dne 23.5.2018 v 16:42 Jens Axboe napsal(a):
>>> On 5/23/18 3:19 AM, Maurizio Lombardi wrote:


 Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
> It's been many years, but back in the day the program writing the cd
> would eject the disc once done. This of course forces a reload of
> the toc and clearing of the flag. What program is this? Seems like
> it should probably eject when it's done.

 They are using wodim to burn the CDs on their servers.
 The problem is that they do not want the CD to be ejected because their 
 drives
 lack a motorized tray, thus requiring manual intervention which they would 
 like to avoid.
>>>
>>> I took a quick look at it, man that sr driver needs a bit of love :-)
>>>
>>> Anyway, I wonder if something like the below would work. Check for
>>> a close track command in the sr completion handler, and flag the media
>>> as changed if we see one. Totally untested...
>>>
>>>
>>> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
>>> index 3f3cb72e0c0c..48f0d7a096db 100644
>>> --- a/drivers/scsi/sr.c
>>> +++ b/drivers/scsi/sr.c
>>> @@ -328,6 +328,9 @@ static int sr_done(struct scsi_cmnd *SCpnt)
>>> scmd_printk(KERN_INFO, SCpnt, "done: %x\n", result);
>>>  #endif
>>>  
>>> +   if (SCpnt->cmnd[0] == GPCMD_CLOSE_TRACK)
>>> +   cd->device->changed = 1;
>>> +
>>> /*
>>>  * Handle MEDIUM ERRORs or VOLUME OVERFLOWs that indicate partial
>>>  * success.  Since this is a relatively rare error condition, no
>>>
>>
>> I just want to let you know that I tested the patch but unfortunately it 
>> doesn't work.
>> I will try to find out what GPCMD_* commands are passed to sr_done() when 
>> burning a disc
>> to see if there is another one which we could use.
> 
> It's been a decade since I last messed with this or burned a cd-r, so that
> would be appreciated. blktrace should be enough to tell you what commands
> are being sent.
> 

You remember this patch? The problem was that after a cd burn operation 
completes,
you can't mount the cd unless you eject it first.

I finally carried out the test you suggested by using blktrace.

This is what I see when a cd burn operation completes:

11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   32 0.357166787 11653  D   W 63488 (2a 00 00 03 3d 02 00 00 
1f 00 ..) [wodim]
 11,03   80 0.922358386 11653  D   W 63488 (2a 00 00 03 3e 57 00 00 
1f 00 ..) [wodim]
 11,03   80 0.922358386 11653  D   W 63488 (2a 00 00 03 3e 57 00 00 
1f 00 ..) [wodim]
 11,03   80 0.922358386 11653  D   W 63488 (2a 00 00 03 3e 57 00 00 
1f 00 ..) [wodim]
 11,03   80 0.922358386 11653  D   W 63488 (2a 00 00 03 3e 57 00 00 
1f 00 ..) [wodim]
 11,03  112 1.332351325 11653  D   W 63488 (2a 00 00 03 3f 4f 00 00 
1f 00 ..) [wodim]
 11,03  112 1.332351325 11653  D   W 63488 (2a 00 00 03 3f 4f 00 00 
1f 00 ..) [wodim]
 11,03  112 1.332351325 11653  D   W 63488 (2a 00 00 03 3f 4f 00 00 
1f 00 ..) [wodim]
 11,03  112 1.332351325 11653  D   W 63488 (2a 00 00 03 3f 4f 00 00 
1f 00 ..) [wodim]
 11,03  152 1.791786352 11653  D   W 63488 (2a 00 00 03 40 66 00 00 
1f 00 ..) [wodim]
 11,03  152 1.791786352 11653  D   W 63488 (2a 00 00 03 40 66 00 00 
1f 00 ..) [wodim]
 11,03  152 1.791786352 11653  D   W 63488 (2a 00 00 03 40 66 00 00 
1f 00 ..) [wodim]
 11,03  152 1.791786352 11653  D   W 63488 (2a 00 00 03 40 66 00 00 
1f 00 ..) [wodim]
 11,03  196 2.357046291 11653  D   W 63488 (2a 00 00 03 41 bb 00 00 
1f 00 ..) [wodim]
 11,03  196 2.357046291 11653  D   W 63488 (2a 00 00 03 41 bb 00 00 
1f 00 ..) [wodim]
 11,03  196 2.357046291 11653  D   W 63488 (2a 00 00 03 41 bb 00 00 
1f 00 ..) [wodim]
 11,03  196 2.357046291 11653  D   W 63488 (2a 00 00 03 41 bb 00 00 
1f 00 ..) [wodim]
 11,03  304 3.600032959 11653  D   N 0 (35 00 ..) [wodim]
 11,03  304 3.600032959 11653  D   N 0 (35 00 ..) [wodim]
 11,03  304 3.600032959 11653  D   N 0 (35 00 ..) [wodim]
 11,03  304 3.600032959 11653  D   N 0 (35 00 ..) [wodim]
 11,03  33218.496219927 11653  D   N 0 (35 00 ..) [wodim]
 11,03  33218.496219927 11653  D   N 0 (35 00 ..) [wodim]
 11,03  33218.496219927 11653  D   N 0 (35 00 ..) [wodim]
 11,03  33218.496219927 11653  D   N 0 (35 00 ..) [wodim]
 11,03  35218.499114653  7433  D   N 0 (00 ..) [kworker/3:2]
 11,03  35218.499114653  7433  D   N 0 (00 ..) 

Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-06-20 Thread Jens Axboe
On 6/20/18 5:52 AM, Maurizio Lombardi wrote:
> Hi Jens,
> 
> Dne 23.5.2018 v 16:42 Jens Axboe napsal(a):
>> On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
>>>
>>>
>>> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
 It's been many years, but back in the day the program writing the cd
 would eject the disc once done. This of course forces a reload of
 the toc and clearing of the flag. What program is this? Seems like
 it should probably eject when it's done.
>>>
>>> They are using wodim to burn the CDs on their servers.
>>> The problem is that they do not want the CD to be ejected because their 
>>> drives
>>> lack a motorized tray, thus requiring manual intervention which they would 
>>> like to avoid.
>>
>> I took a quick look at it, man that sr driver needs a bit of love :-)
>>
>> Anyway, I wonder if something like the below would work. Check for
>> a close track command in the sr completion handler, and flag the media
>> as changed if we see one. Totally untested...
>>
>>
>> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
>> index 3f3cb72e0c0c..48f0d7a096db 100644
>> --- a/drivers/scsi/sr.c
>> +++ b/drivers/scsi/sr.c
>> @@ -328,6 +328,9 @@ static int sr_done(struct scsi_cmnd *SCpnt)
>>  scmd_printk(KERN_INFO, SCpnt, "done: %x\n", result);
>>  #endif
>>  
>> +if (SCpnt->cmnd[0] == GPCMD_CLOSE_TRACK)
>> +cd->device->changed = 1;
>> +
>>  /*
>>   * Handle MEDIUM ERRORs or VOLUME OVERFLOWs that indicate partial
>>   * success.  Since this is a relatively rare error condition, no
>>
> 
> I just want to let you know that I tested the patch but unfortunately it 
> doesn't work.
> I will try to find out what GPCMD_* commands are passed to sr_done() when 
> burning a disc
> to see if there is another one which we could use.

It's been a decade since I last messed with this or burned a cd-r, so that
would be appreciated. blktrace should be enough to tell you what commands
are being sent.

-- 
Jens Axboe



Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-06-20 Thread Maurizio Lombardi
Hi Jens,

Dne 23.5.2018 v 16:42 Jens Axboe napsal(a):
> On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
>>
>>
>> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
>>> It's been many years, but back in the day the program writing the cd
>>> would eject the disc once done. This of course forces a reload of
>>> the toc and clearing of the flag. What program is this? Seems like
>>> it should probably eject when it's done.
>>
>> They are using wodim to burn the CDs on their servers.
>> The problem is that they do not want the CD to be ejected because their 
>> drives
>> lack a motorized tray, thus requiring manual intervention which they would 
>> like to avoid.
> 
> I took a quick look at it, man that sr driver needs a bit of love :-)
> 
> Anyway, I wonder if something like the below would work. Check for
> a close track command in the sr completion handler, and flag the media
> as changed if we see one. Totally untested...
> 
> 
> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> index 3f3cb72e0c0c..48f0d7a096db 100644
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
> @@ -328,6 +328,9 @@ static int sr_done(struct scsi_cmnd *SCpnt)
>   scmd_printk(KERN_INFO, SCpnt, "done: %x\n", result);
>  #endif
>  
> + if (SCpnt->cmnd[0] == GPCMD_CLOSE_TRACK)
> + cd->device->changed = 1;
> +
>   /*
>* Handle MEDIUM ERRORs or VOLUME OVERFLOWs that indicate partial
>* success.  Since this is a relatively rare error condition, no
> 

I just want to let you know that I tested the patch but unfortunately it 
doesn't work.
I will try to find out what GPCMD_* commands are passed to sr_done() when 
burning a disc
to see if there is another one which we could use.

Thanks,
Maurizio


Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-05-23 Thread Maurizio Lombardi


Dne 23.5.2018 v 16:42 Jens Axboe napsal(a):
> On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
>>
>>
>> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
>>> It's been many years, but back in the day the program writing the cd
>>> would eject the disc once done. This of course forces a reload of
>>> the toc and clearing of the flag. What program is this? Seems like
>>> it should probably eject when it's done.
>>
>> They are using wodim to burn the CDs on their servers.
>> The problem is that they do not want the CD to be ejected because their 
>> drives
>> lack a motorized tray, thus requiring manual intervention which they would 
>> like to avoid.
> 
> I took a quick look at it, man that sr driver needs a bit of love :-)
> 
> Anyway, I wonder if something like the below would work. Check for
> a close track command in the sr completion handler, and flag the media
> as changed if we see one. Totally untested...
> 
> 
> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> index 3f3cb72e0c0c..48f0d7a096db 100644
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
> @@ -328,6 +328,9 @@ static int sr_done(struct scsi_cmnd *SCpnt)
>   scmd_printk(KERN_INFO, SCpnt, "done: %x\n", result);
>  #endif
>  
> + if (SCpnt->cmnd[0] == GPCMD_CLOSE_TRACK)
> + cd->device->changed = 1;
> +
>   /*
>* Handle MEDIUM ERRORs or VOLUME OVERFLOWs that indicate partial
>* success.  Since this is a relatively rare error condition, no
> 

Nice! I will test it ASAP and I'll let you know.

Thanks,
Maurizio


Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-05-23 Thread Jens Axboe
On 5/23/18 3:19 AM, Maurizio Lombardi wrote:
> 
> 
> Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
>> It's been many years, but back in the day the program writing the cd
>> would eject the disc once done. This of course forces a reload of
>> the toc and clearing of the flag. What program is this? Seems like
>> it should probably eject when it's done.
> 
> They are using wodim to burn the CDs on their servers.
> The problem is that they do not want the CD to be ejected because their drives
> lack a motorized tray, thus requiring manual intervention which they would 
> like to avoid.

I took a quick look at it, man that sr driver needs a bit of love :-)

Anyway, I wonder if something like the below would work. Check for
a close track command in the sr completion handler, and flag the media
as changed if we see one. Totally untested...


diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 3f3cb72e0c0c..48f0d7a096db 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -328,6 +328,9 @@ static int sr_done(struct scsi_cmnd *SCpnt)
scmd_printk(KERN_INFO, SCpnt, "done: %x\n", result);
 #endif
 
+   if (SCpnt->cmnd[0] == GPCMD_CLOSE_TRACK)
+   cd->device->changed = 1;
+
/*
 * Handle MEDIUM ERRORs or VOLUME OVERFLOWs that indicate partial
 * success.  Since this is a relatively rare error condition, no

-- 
Jens Axboe



Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-05-23 Thread Maurizio Lombardi


Dne 22.5.2018 v 16:47 Jens Axboe napsal(a):
> It's been many years, but back in the day the program writing the cd
> would eject the disc once done. This of course forces a reload of
> the toc and clearing of the flag. What program is this? Seems like
> it should probably eject when it's done.

They are using wodim to burn the CDs on their servers.
The problem is that they do not want the CD to be ejected because their drives
lack a motorized tray, thus requiring manual intervention which they would like 
to avoid.


> 
> There are many commands that will indicate writing to the device, but
> not cause anything that should force a reload. A mode select comes to
> mind.
> 

Ah, I understand... so I have to find a way to distinguish an ongoing cd 
burning process
from, say, a mode select command.

Thanks,
Maurizio


Re: [PATCH RFC] sr: mark the device as changed when burning a CD

2018-05-22 Thread Jens Axboe
On 5/22/18 3:15 AM, Maurizio Lombardi wrote:
> Some of our customers complain that, after burning a CD, it's not possible
> to proceed to mount it without ejecting it first.
> 
> The problem is that the sr driver caches some information about the CD-ROM
> and doesn't update them after burning it, leading to a failure
> when the isofs filesystem tries to read the superblock.
> 
> This patch modifies the sr driver so it detects the SG_IO
> write ioctls and marks the device as "changed".
> As a result, at the next open() syscall, the revalidate_block()
> callback will be executed and the sr driver will update its cached info.
> 
> Is this patch acceptable to you? Do you have different ideas?

It's been many years, but back in the day the program writing the cd
would eject the disc once done. This of course forces a reload of
the toc and clearing of the flag. What program is this? Seems like
it should probably eject when it's done.

There are many commands that will indicate writing to the device, but
not cause anything that should force a reload. A mode select comes to
mind.

-- 
Jens Axboe



[PATCH RFC] sr: mark the device as changed when burning a CD

2018-05-22 Thread Maurizio Lombardi
Some of our customers complain that, after burning a CD, it's not possible
to proceed to mount it without ejecting it first.

The problem is that the sr driver caches some information about the CD-ROM
and doesn't update them after burning it, leading to a failure
when the isofs filesystem tries to read the superblock.

This patch modifies the sr driver so it detects the SG_IO
write ioctls and marks the device as "changed".
As a result, at the next open() syscall, the revalidate_block()
callback will be executed and the sr driver will update its cached info.

Is this patch acceptable to you? Do you have different ideas?

Maurizio Lombardi (1):
  sr: mark device as changed when performing a write SG_IO operation

 drivers/scsi/sr.c | 8 
 1 file changed, 8 insertions(+)

-- 
Maurizio Lombardi