FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

LinkBack Thread Tools
Old 05-01-2012, 03:42 PM
Brassow Jonathan
Default dm: update max_io_len to support a split_io that is not a power of 2

On Apr 30, 2012, at 1:59 PM, Mike Snitzer wrote:I cannot see why we'd need a split_io that is larger than 32 bits -- a
32bit split_io can support up to 2TB (2**32 * 512b sectors). *Even
on a LBD (raid) the stripe size (split_io) will not be so large.

But is that enforced in the raid code or not?

No idea, need Jon to weigh in here. *I'm hopeful we can impose 32bit
within dm-raid and coordinate with Neil on getting the appropriate MD
code (chunk_sectors) to reflect the reality that 32 bit is adequate.

But what I think what you're driving at is:*

(I'm not convinced the proposed patch has been tested on 32-bit+LBD,
attempting to divide by a 64-bit number etc.)

Right, it wasn't tested on 32bit. *It'll fail to build due to split_io
being sector_t.

is there a benefit/reason to
maintain the old code for some target that won't ever use non power of 2
split_io (e.g. dm-raid at the moment)? *I see no point for the duality
in the code but I'm open to the idea if you have a specific reason in
mind -- are you concerned about perf on more obscure/older hardware?

EITHER the 32 bit split_io *must* be enforced (after we've convinced
ourselves 64 bits will never be required);
OR we keep it 64-bit and add some compat code.

Yeap, I'm hopeful we can go with the former.

Jon, what do you think?
split_io is used by dm-raid to split I/O on 'region_size' and 'chunk_size' boundaries. *The former is used for bitmap purposes for the write intent log (RAID 1/4/5/6). *The later is used by striping targets (RAID 4/5/6). *There are some sanity checks. *They must *be power of 2, region_size must be larger than 'chunk_size', etc. *However, I don't see any enforcement on the size of those numbers. *There probably should be, given that 'chunk_sectors'/'stripe_sectors' are 32-bit 'int' types. *Additionally, 'chunksize' (the name given for 'region_size' in MD) is a 32-bit type on disk and 'unsigned long' in memory - with no checking for size when the in-memory version is stored on disk.
I think these checks should probably be added, but there would be a limitation on the size of arrays imposed, I think. *Neil mentioned that the maximum size of a bitmap was (1 << 21) bits. *If the max 'region_size' is (1 << 32), then the max size device is (1 << 21) * (1 << 32) * (1 << 9) = 4 EiB. *I don't think that's a problem.
dm-devel mailing list

Thread Tools

All times are GMT. The time now is 12:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org