On Tue, 2016-04-26 at 01:33 -0700, hch@xxxxxxxxxxxxx wrote: > On Mon, Apr 25, 2016 at 05:14:36PM +0000, Verma, Vishal L wrote: > > > > - Application hits EIO doing dax_IO or load/store io > > > > - It checks badblocks and discovers it's files have lost data > > > > - It write()s those sectors (possibly converted to file offsets > > using > > fiemap) > > ?? ?? * This triggers the fallback path, but if the application is > > doing > > this level of recovery, it will know the sector is bad, and write > > the > > entire sector > This sounds like a mess. > > > > > I think if we want to keep allowing arbitrary alignments for the > > dax_do_io path, we'd need: > > 1. To represent badblocks at a finer granularity (likely cache > > lines) > > 2. To allow the driver to do IO to a *block device* at sub-sector > > granularity > It's not a block device if it supports DAX. It's byte addressable > memory masquerading as a block device. Yes but we made that decision a while back with pmem :) Are you saying it should stop being a block device anymore? > -- > To unsubscribe from this list: send the line "unsubscribe linux- > block" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>