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
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
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/
_
****************************************************************
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 [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On 11/15/06, Phillip Susi <[email protected]> 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
>
>
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.