locking sectors of raw disk (raw read-write test of mounted disk)

locking sectors of raw disk (raw read-write test of mounted disk)

[Yakov Lerner]

I'd like to make read-write test of the raw disk, and disk has
mounted partitions. Is it possible to lock  range of sectors
of the raw device so that any kernel code that wants to write
to this range will sleep ? (so that test
    { lock range; read /dev/hda->buf; write buf->/dev/hda; unlock }
won't corrupt the filesysyem ?)

Thanks
Yakov

Re: locking sectors of raw disk (raw read-write test of mounted disk)

[Phillip Susi]

No, you can not tamper with the underlying data while the kernel has it 
mounted.

Yakov Lerner wrote:
> I'd like to make read-write test of the raw disk, and disk has
> mounted partitions. Is it possible to lock  range of sectors
> of the raw device so that any kernel code that wants to write
> to this range will sleep ? (so that test
>    { lock range; read /dev/hda->buf; write buf->/dev/hda; unlock }
> won't corrupt the filesysyem ?)
> 
> Thanks
> Yakov

Re: locking sectors of raw disk (raw read-write test of mounted disk)

[linux-os (Dick Johnson)]

On Wed, 15 Nov 2006, Phillip Susi wrote:

> No, you can not tamper with the underlying data while the kernel has it
> mounted.
>
> Yakov Lerner wrote:
>> I'd like to make read-write test of the raw disk, and disk has
>> mounted partitions. Is it possible to lock  range of sectors
>> of the raw device so that any kernel code that wants to write
>> to this range will sleep ? (so that test
>>    { lock range; read /dev/hda->buf; write buf->/dev/hda; unlock }
>> won't corrupt the filesysyem ?)
>>
>> Thanks
>> Yakov
>

Well certainly if the low-level driver was modified, or a new one
created, so that one could lock/unlock a range of sectors, then that
would be possible. You would need to save (somewhere) the original
sector data, then put it back before unlocking that range. You couldn't
save the original data in a file on the disk, because that file-data
may (someday) extend into the locked region and you have a deadlock.

In the "good old days" when a SCSI format block command actually
worked, we could repair bad sectors by doing just that. We would
lock the block, save whatever data was readable in that block,
format that block, write the data back, then release the lock.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.72 BogoMips).
New book: http://www.AbominableFirebug.com/
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: locking sectors of raw disk (raw read-write test of mounted disk)

[Yakov Lerner]

On 11/15/06, Phillip Susi <psusi@cfl.rr.com> wrote:
> No, you can not tamper with the underlying data while the kernel has it
> mounted.
I don't want to tamper wuith data. I want to raw write back exacty
same raw data that I read in. I only want to make sure that kernel
doesn't write modified data between in between my read-write pair.

Yakov


> Yakov Lerner wrote:
> > I'd like to make read-write test of the raw disk, and disk has
> > mounted partitions. Is it possible to lock  range of sectors
> > of the raw device so that any kernel code that wants to write
> > to this range will sleep ? (so that test
> >    { lock range; read /dev/hda->buf; write buf->/dev/hda; unlock }
> > won't corrupt the filesysyem ?)
> >
> > Thanks
> > Yakov
>
>

Re: locking sectors of raw disk (raw read-write test of mounted disk)

[Phillip Susi]

Yakov Lerner wrote:
> I don't want to tamper wuith data. I want to raw write back exacty
> same raw data that I read in. I only want to make sure that kernel
> doesn't write modified data between in between my read-write pair.

Ahh, in that case you might be able to do this using the device mapper. 
  You could keep the filesystem mounted on the device mapper with a 
mapping to the underlying disk device.  Then change that mapping on the 
fly to mark a section of the device as mapped to a ramdisk and copy ( 
while that section is suspended ) the original data there.  Then resume 
the section, tamper with the underlying disk, then suspend the ramdisk 
mapping, copy it back to the underlying disk, then change the mapping 
back to normal.  You might also use a snapshot dm target instead of a 
ramdisk.