[Lustre-devel] Moving forward on Quotas
Zhiyong.Tian at Sun.COM
Tue Jun 3 01:49:46 PDT 2008
>From: lustre-devel-bounces at lists.lustre.org
>[mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Andreas Dilger
>Sent: Tuesday, June 03, 2008 7:25 AM
>To: Peter Braam
>Cc: Bryon Neitzel; Johann Lombardi; Peter Bojanic; Jessica A. Johnson; Eric
>Barton; Nikita Danilov; lustre-devel at lists.lustre.org
>Subject: Re: [Lustre-devel] Moving forward on Quotas
>On Jun 01, 2008 10:32 +0800, Peter J. Braam wrote:
>> I am quite worried about the dynamic qunit patch.
>> I am not convinced I want smaller qunits to stick around.
>> Please PROVE RIGOROUSLY that qunits are grow large quickly again,
>> they create too much server - server overhead. The cost of 100MB of disk
>> space is barely more than a cent now; what are we trying to address
>> Plan for 5000 OSS servers at the minimum and 1,000,000 clients, and up to
>> 100TB/sec in I/O. Calculate quota RPC traffic from that. A server
>> handle more than 15,000 RPC's / sec.
>> No arguing, or opinions here, numbers please. The original design I did
>> years ago limited quota calls from one OSS to the master to one per
>> Qunits were made adaptive without solid reasoning or design.
>Just a note - it isn't only shrinking of qunits that is possible, but also
>growth of qunits. I think there was also work done to allow recall of
>qunits from the servers, but I'm not sure if it was landed into CVS.
Yes, it has. In order to prevent ping-pong effect, if qunit is reduced,
qunit _only_ could be
Increased after the_latest_qunit_reduction + lqc_switch_seconds(default is
300 secs) .
At designing, we think accuracy is more urgent(otherwise, users will see
so decreasing can be done any time, but increasing has this limitation.
More information about the lustre-devel