-- Cyril SCETBON > 1) but is the rewrite in that, or in > 3.17, or in the coming 3.18, or not yet entirely there at all... that I > simply don't know. If anyone can answer it'd be great ! > > 2) What I *DO* know and *CAN* say with quite some confidence is this: > > With btrfs being in general a copy-on-write filesystem, even deletes > normally require /some/ space, because the metadata pointing at the file > in question must be rewritten, and that requires free space in ordered to > happen. ok > > At least in the case of full filesystem ENOSPC errors, the space-related > questions in the FAQ on the btrfs wiki suggest truncating a file first. > Find an existing file that either doesn't matter or that you have a > backup of elsewhere, and echo > filename (or echo >| filename if you have > noclobber set), therefore truncating the existing file. A few of those > and with luck you'll free enough space to do some actual deletions. > > While to some extent I'm guessing here since I'm not directly familiar > with quotas myself, it sounds as if such a severe ENOSPC condition, due > in your case to quotas instead of the general filesystem limits I'm more > familiar with, might be what you are seeing, particularly since in your > tests you first triggered the limit, then found a way to write a bit more > anyway, and only THEN found yourself unable to write anything. > > If that's the case, then try the truncate trick and see if it helps. Unfortunately : http://pastebin.com/1Mw0yiUc > > In the generic filesystem case, if the truncate trick doesn't help, > another possible trick is to temporarily add another device of several > gigs capacity to the filesystem, enough to let a balance work and > hopefully reduce the data/metadata imbalance, after which there should be > enough chunk-unallocated free space left on the original device, to do a > btrfs device delete of the temporary device, generally still leaving > space left, since the balance should have reclaimed some otherwise wasted > chunk allocation. > > I can't see how that'd apply to quotas, however, and suspect that the > corresponding quota-system solution would be to temporarily up the quota > for the affected user, only long enough to let them do the deletions they > need to do. But beyond that I can't go, since I simply don't know enough > about the quota domain to further speculate, at this point. I'm pretty sure it'd work by setting a temporary higher quota, but my questions are : - why can I exceed the quotas (580MB when 500MB was set as the limit) ? qgroupid excl max_excl ------------------------------------------- 1/101999 608632832 524288000 - I really think that the quota limit should take into account an amount of space for operations that would free space For this last question I may think that this issue is caused by the fact that I have only one file taking all the space which won't really be the regular use case. but i'd like to get an answer :) > > While admittedly limited due to my lack of quota-domain knowledge, > perhaps that sheds at least some light on what happened and why, and > hopefully on how to get out of the situation. Thank you Duncan !-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
