Re: mmotm 2012-06-21-16-20 uploaded (dm-thin)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Sun, Jun 24, 2012 at 05:55:55PM +0100, Alasdair G Kergon wrote:
> Ah yes, I'll fix that, and check we handle "too large" devices sensibly.
What does it mean when sector_t is 32 bits but dm_block_t is 64 bits?

- You're loading a large pool device you created on a system where sector_t was 64 bits?
  (and we refuse to load this device)

- The top 32 bits of dm_block_t would always be zero so we should make
dm_block_t match the type of sector_t?
(Because blocks are bigger than sectors?)

int sm_ll_extend(struct ll_disk *ll, dm_block_t extra_blocks)

        old_blocks = dm_sector_div_up(ll->nr_blocks, ll->entries_per_block);

[ll->nr_blocks is 64 bits]

#define dm_sector_div_up(n, sz) ( \
{ \
        sector_t _r = ((n) + (sz) - 1); \

[sector_t might be 32 bits => truncation]

        sector_div(_r, (sz)); \
        _r; \
} \


dm-devel mailing list

[DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

Add to Google Powered by Linux