On Tue, Mar 19, 2013 at 12:04 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > >> > BTW, I wonder what's the right locking for that sucker; overlayfs is >> > probably too heavy - we are talking about copying a file from one fs to >> > another, which can obviously take quite a while, so holding ->i_mutex on >> > _parent_ all along is asking for very serious contention. >> >> Copy up is a once-in-a-lifetime event for an object. Optimizing it is >> way down in the list of things to do. I'd drop splice in a jiffy if >> it's in the way. > > Yes, but it could block the parent directory for a long time. I suspect it's > fine if you can RCU walk through the parent, but if you have to grab a lock on > it... Right. Lets look at it this way: users of an overlay accept that an operation X can take T time, where T is much longer than would be on a normal filesystem. Then why would they complain that operation Y (which happens to bump into the parent lock of X) also takes T? If copy up of huge files happens more then very very occasionally, then the overlay will be basically unusable anyway. It's just not what it is designed for, so why try to optimize this case? Thanks, Miklos -- 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
