[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dm-devel
Subject:    Re: [dm-devel] mmotm 2012-06-21-16-20 uploaded (dm-thin)
From:       Alasdair G Kergon <agk () redhat ! com>
Date:       2012-06-24 18:34:50
Message-ID: 20120624183449.GB17647 () agk-dp ! fab ! redhat ! com
[Download RAW message or body]

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; \
} \
)

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic