Messages in this thread | | | Subject | Re: [PATCH 1/4] loop: Enable correct physical blocksize | From | Hannes Reinecke <> | Date | Tue, 1 Dec 2015 10:32:01 +0100 |
| |
On 11/13/2015 09:57 PM, Jeff Moyer wrote: > Hi Hannes, > > Hannes Reinecke <hare@suse.de> writes: > >> When running on files the physical blocksize is actually 4k, > > How did you come to that conclusion? Are you basing it on the file > system block size? If so, that's configurable at mkfs time and can be > anything from 512 bytes to 64k on current in-tree file systems that I > know of (depending on platform, of course). > loop.c does this (in do_loop_switch()):
mapping_set_gfp_mask(old_file->f_mapping, lo->old_gfp_mask); lo->lo_backing_file = file; lo->lo_blocksize = S_ISBLK(mapping->host->i_mode) ? mapping->host->i_bdev->bd_block_size : PAGE_SIZE; lo->old_gfp_mask = mapping_gfp_mask(mapping);
So either it's a block device, then we're taking the blocksize of the underlying device, or we're using PAGE_SIZE. Which is architecture dependent, of course.
> The main use for physical block size, as I understand it, is to allow > partitioning utilities to place partitions on physical block boundaries > of the underlying storage. The benefit of that is to avoid > read-modify-writes for I/O which is naturally sized and aligned. If we > carry that forward to loop, then I think it does makes sense to key off > of the file system block size, but the fact remains that 4k is not > universal. > The main point here is that some utilities (eg bootloaders) need to know the _physical_ location of a particular blob, for which it needs to know the physical blocksize.
> So, I think the idea is sound, but you should be setting the physical > block size to sb->s_blocksize. And I don't see any reason why we > wouldn't do this by default, do you? > Neither do I. But the code doesn't treat it that way, so I elected to stay with the current version.
> If you end up reposting this patch, would you mind including more of > this rationale in your commit message? > Sure.
Cheers,
Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
| |