On Fri, Jun 26, 2009 at 10:42:25AM +0200, Nick Piggin wrote: > Yes well we could get rid of ->truncate and have filesystems do it > themselves in setattr, but I figure that moving truncate into > generic setattr is helpful (makes conversions a bit easier too). > Did you see my patch? What do you think of that basic approach? I was waiting for a patch series for your for this to appear, but noticed that you actually had a small proof of concept patch attached, sorry :) Looking at your patch I really like that vmtruncate now really just does what it's name claims to - truncate the VM-information about the file (well, and the file size). I'm not so happy about still keeping the two level setattr/truncate indirection. But instead of folding truncate into setattr I wonder if we should just add a new ->setsize (aka new trunacte) methodas a top-level entry point instead of ->setattr with ATTR_SIZE given that size changes don't have much in common with the reset of ->setattr. The only bit shared is updating c/mtime and even that is conditional. So I'd say take most of your patch, but instead of doing an all at once migration migrate filesystems to the new ->setsize callback incrementally and eventually kill off the old code. This means we'll need a new name for the new vmtruncate-lite but should otherwise be pretty easy. > > The only problem is the generic aops calling > > vmtruncate directly. > > What should be done is require that filesystems trim blocks past > i_size in case of any errors. I actually need to fix up a few > existing bugs in this area too, so I'll look at this.. Basically we want ->setattr with ATTR_SIZE, execept that we already have i_sem and possibly other per-inode locks. Take a look at http://oss.sgi.com/archives/xfs/2008-04/msg00542.html and http://oss.sgi.com/archives/xfs/2009-03/msg00214.html -- 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
