From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhiyong Landen tian Subject: Re: [PATCH] quota: additional range checks and mem_dqblk updates?to handle 64-bit limits Date: Tue, 11 Mar 2008 11:16:02 +0800 Message-ID: <47D5F972.10504@sun.com> References: <200803070329.29774.andrew.perepechko@sun.com> <20080307160043.GA16967@duck.suse.cz> <200803080356.18583.andrew.perepechko@sun.com> <20080310152059.GJ24873@duck.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Andrew Perepechko , linux-fsdevel@vger.kernel.org, Johann Lombardi To: Jan Kara Return-path: Received: from sineb-mail-2.sun.com ([192.18.19.7]:32997 "EHLO sineb-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752857AbYCKDWx (ORCPT ); Mon, 10 Mar 2008 23:22:53 -0400 Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2B3GN0h014750 for ; Tue, 11 Mar 2008 03:16:26 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXJ00B01QD4N700@mail-apac.sun.com> (original mail from Zhiyong.Tian@Sun.COM) for linux-fsdevel@vger.kernel.org; Tue, 11 Mar 2008 11:16:05 +0800 (SGT) In-reply-to: <20080310152059.GJ24873@duck.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Jan Kara wrote: > On Sat 08-03-08 03:56:17, Andrew Perepechko wrote: > >> Jan, this idea would work for us for now. As Andreas pointed out, we deal >> with MB-aligned quota limits, so this would give us the largest possible block >> quota limit value of 4 PB. >> >> However, I feel that it is worth to implement a clean 64-bit format, so that >> we avoid additional semantics (like quota unit size) and do make quota scale >> better (4 PB clusters already exist). >> > Wow. I wonder when 64-bits won't be enough :). Anyway, my point was that > when you get to 4 PB limits, you can just run: "setquota --set-scale 1GB" > (hopefully at that time you won't care about rounding limits to 1GB) and > you are at 4 HB limits (or what is the right suffix). No quota format > change needed. > But what I fear more is that we may run out of 2^32 limit on the number > of files one user can have (I don't have experience with that large systems > but I guess you are comming near to 2^32 files on the filesystem, aren't > you?). And for that we would have to do basically the changes you've > suggested The core of the "scale" way is: it does harm to the accuracy of quota so that we can set a larger quota limitation. If the scale is 1G, 500M quota the user sets is equal to 0. Some customers may like it; others may confuse. Anyway, we can't regulate the way of users using quota. For lustre, I have a plan to set a minimum unit to 1K instead of current 1M. So 64bit quota is a must. I just wonder why not we implement these two points in different patches: 1. 64bit quota limitation 2. give a "scale" to the users who are glad to adjust it.