Re: allocation bitmaps

[Florian Sedivy]

Hello Antonio! 

> Antonio Diaz Diaz <antonio@gnu.org> wrote:
> Hi Florian,
> 
> Florian Sedivy wrote:
>> I propose to concentrate on the raw format, just as those allocation
>> bitmaps are stored on the drive by the respective filesystem
>> specifications. That makes ddrescuelog independent of the possibly
>> proprietary formats some tools would use to store backups of them. More
>> importantly it allows reading or writing those bitmap files with direct
>> disk access tools - like ddrescue.
> 
> Even concentrating on the raw format seems to need a lot of research work. 
> For example, given an image of a partition with a file system of type ext3, 
> what is the command required to read the block bitmap(s) from the image using 
> ddrescue? What is the mapping between file system blocks and drive sectors?
> 
> As time permits, I'll try to investigate this for ext2/3/4 file systems. 
> Concrete data (command used and format of resulting bitmap file) for these or 
> other types are welcome.

I don't think ddrescue or ddrescuelog need to include knowledge about the 
location, mapping or meaning of allocation bitmaps. It also doesn't "know" 
about partition maps, volumes, volume headers, filesystems, the mapping between 
a block-list and drive sectors, how to get a block-list from a filesystem or 
where to use one, etc. 

The necessary knowledge has to be brought by the user, as for block-lists. 
After all an allocation bitmap is nothing more than an alternative 
representation of a block-list. All the tools needed are there already, for 
those who know what they are doing: offset, block size and size. The only thing 
missing is "raw bitmap" or "binary" (optionally little- or big-endian) as an 
alternative input and output format for ddrescuelog's block-list. 

Greetings, 
Florian