Mike Snitzer d715803d45 devmapper: revert the default dm-thin-pool blocksize back to 64K ... Commit 09ee269d ("devmapper: Add option for specifying the thin pool blocksize") also switched the default dm-thin-pool blocksize from 64K to 512K. That change unfortunately breaks the activation of dm-thin-pool devices that were previously created using a 64K blocksize. Here is an example of the dm-thin-pool activation failure users may experience: device-mapper: thin: 253:4: pool target (204800 blocks) too small: expected 1638400 device-mapper: table: 253:4: thin-pool: preresume failed, error = -22 The reason for this is docker is passing 512K as the blocksize for a dm-thin-pool that was previously created using a 64K blocksize. Docker doesn't record the blocksize the is used when it creates a dm-thin-pool. Until now it never had a need to do so because the blocksize was always hardcoded. The dm-thin-pool blocksize must be the same every time a dm-thin-pool is activated. As a stop-gap fix, revert to using 64K for the default blocksize. But we do need a proper fix for this now that 'dm.blocksize' is exposed as a proper storage option. One possible fix would be to record the blocksize for each dm-thin-pool that docker creates and to pass that recorded blocksize down in the dmsetup table load each time the dm-thin-pool is activated (this would be comparable to what lvm2 does). Docker-DCO-1.1-Signed-off-by: Mike Snitzer <snitzer@redhat.com> (github: snitm)		2014-07-09 16:47:30 -04:00
..
aufs	Change misnamed TarFilter to TarWithOptions	2014-06-26 22:49:08 +00:00
btrfs	Move remount as private to the graph drivers	2014-06-05 16:02:25 -07:00
devmapper	devmapper: revert the default dm-thin-pool blocksize back to 64K	2014-07-09 16:47:30 -04:00
graphtest	Fix go vet errors	2014-06-18 17:39:57 +00:00
vfs	cp's -T and --reflink=auto are only available on GNU coreutils	2014-06-24 23:58:17 +09:00
driver.go	Move remount as private to the graph drivers	2014-06-05 16:02:25 -07:00