[DRBD-user] BLKFLSBUF: Inappropriate ioctl for device (when executing blockdev --flushbufs)

Werner Fischer werner.fischer at fh-hagenberg.at
Thu Sep 28 16:23:46 CEST 2006

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Thu, 2006-09-28 at 11:18 +0200, Lars Ellenberg wrote:
> the reason it "works" here, and not for you is probably this,
> from kernel ChangeLog-2.6.9:
> <ecashin at coraid.com>
>  [PATCH] fix block layer ioctl bug
>  If the blockdev doesn't implement BLKFLSBUF and returns -ENOTTY we should
>  still go ahead and perform the VFS-level sync.  We need to test for both
>  ENOTTY and EINVAL because some SCSI drivers incorrectly return EINVAL.
>  Signed-off-by: Ed L Cashin <ecashin at coraid.com>
>  Signed-off-by: Andrew Morton <akpm at osdl.org>
>  Signed-off-by: Linus Torvalds <torvalds at osdl.org>
> > On your side: what does DRBD upon "blockdev --flushbufs /dev/drbd0" - 
> > does DRBD forward the flush command to the lower devices?
> DRBD does nothing but return ENOTTY...
> Maybe we want to put something in there, like you suggest.
> but (for kernels including the patch mentioned above),
> block/ioctl.c blkdev_ioctl() does the right thing, namely:
>     lock_kernel();
>     fsync_bdev(bdev);
>     invalidate_bdev(bdev, 0);
>     unlock_kernel();
>     return 0;
> so I think there is no hurry...
I think you are right for kernels >= 2.6.9

Do you see a problem in using DRBD in kernel 2.6.8 (without the patch
mentioned above)?

As far as I understand it, with kernel 2.6.8 (without the patch) this
"VFS-level sync" is not done. Can this lead to any problems when I use


More information about the drbd-user mailing list