Hi Sage, On Sat, 2010-12-04 at 21:59 -0700, Sage Weil wrote: > > > > > 4) recreate files, same size/name as step 2); > > > > > > > > Note that this step takes _much_ longer: 1448 sec vs. 41 sec. > > > > Maybe redirecting stdout onto a file from an echo of nothing > > > > is a really stupid way to truncate a file, but still... > > > > seems like something might not be right? > > When you say 'recreate', you mean you 0-truncate the file, and then reopen > and write new data, right? It's not a _new_ file that happens to have the > same name?
Yes, I 0-truncate the file, then open that same file again. > > My first guess is that it's related to the fact that the truncate is done > on a different client and the 'wanted' caps aren't getting released, > forcing IO to be synchronous. Can you repeat that experiment, but > write + truncate + rewrite all on the same node? Yes, it definitely matters on which clients the operations occur. If the create, 0-truncate, rewrite all happen on the same client, all is well. If I truncate a file on a different client, I see the slowdown. -- Jim > > It may also be that there is some contention on the OSDs due to the object > deletes going in parallel with the new data being written. I wouldn't > expect that to be an issue though... :/ > > Thanks! > sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
