On Fri, Mar 09, 2012 at 11:17:10AM +1100, Dave Chinner wrote: > On Thu, Mar 08, 2012 at 10:23:48AM -0600, Ben Myers wrote: > > On Thu, Mar 08, 2012 at 01:10:54PM +1100, Dave Chinner wrote: > > > On Wed, Mar 07, 2012 at 12:04:26PM -0600, Eric Sandeen wrote: > Alex and I discussed this problem briefly awhile ago. What is the best > > way to lose when you hit ENOSPC (project quotas) or EDQUOT in > > xfs_iomap_write_delay? You want to be fair; one user hitting his quota > > shouldn't be able to steal some other user's block reservations unless > > you really are near ENOSPC for the entire filesystem. > > > > I suggested something like... track inodes with preallocated block > > reservations in LRU order and by dquot, so that the poor fella who is at > > EDQUOT will first clean up the preallocations that resulted in quota > > being enforced, try again, and then work on preallocations of other > > users only if it can help in his situation. IIRC Alex shut me down when > > he heard LRU. ;) > > And I agree with Alex. Nothing additional needs to be tracked on top > of inodes with speculative prealloc. Just the search filter would > need to be different (i.e. only select inodes with a specific dquot > attached). Yeah, maybe not. A single list of inodes with speculative prealloc does seem a good place to start. Later maybe you would not want to scan/filter through all of them and we could add additional lists for dquots. My suggestion of using LRU was because I think that the oldest unused speculative preallocs should be the first to go. One chronic over-quota user shouldn't be able to punish everyone else. > > Now that block reservations count toward quotas the symptom will > > probably be a little different. > > Block reservations have always counted towards quotas, it's just > that they were never reported. Aw. My mistake. ;) -Ben _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
