Fair enough if somebody is running this file system I would be happy to have someone test my code in order to fix this. Cheers Nick On Fri, Jun 20, 2014 at 10:38 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 20 Jun 2014 22:25:47 -0400 Nick Krause <xerofoify@xxxxxxxxx> wrote: > >> If you have any ideas about what is better >> please let me known. > > I think the proposed patch was not a good one - it will cause truncate > to silently return, probably leaving the fs in an inconsistent state. > Neither the user nor the running application know this happened so they > will just keep on modifying the filesystem, possibly mangling it > further. > > The code as it stands at present is better - if bread() fails we'll get > a nice solid oops and the current app will be terminated (at least). > As we're in truncate it's quite possible that the entire fs will get > wedged up due to now-permanently-held i_mutex, which is even better. > > > As for the best fix, umm, hard. We're pretty screwed if we cannot read > that block at this code site. Perhaps emit loud printks, forcibly turn > the fs read-only then return -EIO/-ENOMEM/etc from the truncate. Such > a change would require runtime testing, with some form of developer fault > injection. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
