Hey, I did some new tests and the issue with quota exceeded comes from the fact that the data is not sync to disk : http://pastebin.com/fZdh2YRu
-- Cyril SCETBON > On 09 Nov 2014, at 18:55, Cyril Scetbon <cyril.scet...@free.fr> wrote: > > > -- > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
