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 DRBD? Greetings, Werner