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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
