| 1 |
Who's paying for this bandwith? |
| 2 |
|
| 3 |
N. |
| 4 |
|
| 5 |
On 4/24/13, Neil Bothwick <neil@××××××××××.uk> wrote: |
| 6 |
> On Wed, 24 Apr 2013 19:07:05 +0100, Stroller wrote: |
| 7 |
> |
| 8 |
>> > That only works on small systems. I have systems here where a 'du' on |
| 9 |
>> > /home would take hours and produce massive IO wait, because there's so |
| 10 |
>> > much data in there. |
| 11 |
>> |
| 12 |
>> Of course. Excuse me. |
| 13 |
>> |
| 14 |
>> My original idea was in respect of the previous respondent's desire to |
| 15 |
>> offer hard limits of a gigabyte - allocating each user a partition and |
| 16 |
>> running `du`, which returns immediately, on it. |
| 17 |
> |
| 18 |
> I said "by the gigabyte" not "of a gigabyte", a user could have hundreds |
| 19 |
> of them. |
| 20 |
> |
| 21 |
>> I don't understand how a hard limit could be enforced if it's |
| 22 |
>> impractical to assess the size of used data. |
| 23 |
> |
| 24 |
> Because the filesystem keeps track of the usage, just like it does for |
| 25 |
> the whole filesystem, which is why "df ." is so much faster than |
| 26 |
> "du .". ZFS does this too, it just doesn't have a concept of a soft limit. |
| 27 |
> |
| 28 |
> |
| 29 |
> -- |
| 30 |
> Neil Bothwick |
| 31 |
> |
| 32 |
> Please rotate your phone 90 degrees and try again. |
| 33 |
> |
Archives