[dm-devel] blockdev --flushbufs required [was: parted issue/question
Zdenek Kabelac
zkabelac at redhat.com
Wed Jan 18 14:05:14 UTC 2012
Dne 18.1.2012 14:44, Jim Meyering napsal(a):
> [Following up on this thread:
> http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/14999]
>
> Alasdair G Kergon wrote:
>> Try
>> blkdev --flushbufs
>> after any cmd that writes to a dev to see if that makes any difference.
>
> Thanks for the work-around.
> Using "blockdev --flushbufs $dev" does indeed make parted
> behave the same with dm-backed storage as with other devices.
>
> Adjusting my small example,
>
> cd /tmp; truncate -s 10m g&& loop=$(losetup --show -f g)
> echo 0 100 linear $loop 0 | dmsetup create zub
> dev=/dev/mapper/zub
> parted -s $dev \
> mklabel gpt \
> mkpart efi 34s 34s \
> mkpart root 35s 35s \
> mkpart roo2 36s 36s \
> u s p
> blockdev --flushbufs $dev # FIXME: required with device-mapper-1.02.65-5
>
> # write random bits to p1
> dd of=${dev}p1 if=/dev/urandom count=1
> dd if=${dev}p1 of=p1-copy.pre count=1
> parted -s $dev mkpart p4 37s 37s
> blockdev --flushbufs $dev # FIXME: required with device-mapper-1.02.65-5
>
> dd if=${dev}p1 of=p1-copy.post count=1
> cmp -l p1-copy.pre p1-copy.post
>
> With that, the "cmp" show no differences.
>
> Does this sound like a problem in device-mapper land,
> or in how parted interacts with DM?
Just my wild guess it could be related to wrong assumption that close of
descriptor means automatic flush - this is only true in the case, there is
only one user for descriptor so it would be the last user - but if e.g. the
device is opened more then once, then close doesn't mean flush - so I'd have
assume some application is missing fsync(fd) before doing close(fd).
Zdenek
More information about the dm-devel
mailing list