On Sat, Dec 04, 2010 at 04:11:40AM +1100, Nick Piggin wrote: > > Alternatively, what about switching brd away from overloading BLKFLSBUF > > to a real implementation of (overloaded) BLKDISCARD support in brd.c? > > One that doesn't blindly nuke the entire device but that properly > > processes the discard request. > > Yeah the situation really sucks (mkfs.jfs doesn't work on ramdisk > for the same reason). > > I want to unfortunately keep ioctl for compatibility, but adding new > saner ones would be welcome. Also, having a non-default config or > load time parameter for brd, to skip the special case, if that would > help testing on older userspace. How many programs actually depend on BLKFLSBUF dropping the pages used in /dev/ram? The fact that it did this at all was a historical accident of how the original /dev/ram was implemented (in the buffer cache directly), and not anything that was intended. I think that's something that we should be able to fix, since the number of programs that knowly operate on the ramdisk is quite small. Just a few system programs used by distributions in their early boot scripts.... So I would argue for dropping the "special" behavior of BLKFLSBUF for /dev/ram. - Ted _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
