linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andrew Perepechko <Andrew.Perepechko@Sun.COM>
Cc: linux-fsdevel@vger.kernel.org,
	Johann Lombardi <Johann.Lombardi@Sun.COM>,
	Zhiyong Landen tian <Zhiyong.Tian@Sun.COM>
Subject: Re: [PATCH] quota: additional range checks and mem_dqblk updates?to handle 64-bit limits
Date: Mon, 10 Mar 2008 16:20:59 +0100	[thread overview]
Message-ID: <20080310152059.GJ24873@duck.suse.cz> (raw)
In-Reply-To: <200803080356.18583.andrew.perepechko@sun.com>

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.

> Do you feel it might take considerably larger efforts to update quotatools
> to 64-bit version compared to 32-bit version with variable quota unit size?
  Well, I don't fear that much about quota tools but more about the kernel
code and duplication of code in there.

> I'd like to start working on a kernel patch implementing 64-bit limits provided 
> you approve the approach.
  I'm glad you're eager to work on that :) I'd just like to think twice
before going for the new format and changing quota code.

> Of course, it seems to be a good idea to have different file names for each version,
> not only for each format (where format and version have the same meaning
> as in quota kernel modules). The drawback is that then journalling quota users 
> need to know the exact quota file version, not only format...
  Hmm, I don't get this. I don't think there's a real need for changing the
quota file name. That is exactly what I'd like to avoid. Why do you think
new quota file name is better? Those conversion things Andreas pointed out,
are solved by doing the conversion into the temporary file...

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2008-03-10 15:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-07  0:29 [PATCH] quota: additional range checks and mem_dqblk updates to handle 64-bit limits Andrew Perepechko
2008-03-07 16:00 ` Jan Kara
2008-03-07 21:10   ` Andreas Dilger
2008-03-10 14:54     ` Jan Kara
2008-03-08  0:56   ` Andrew Perepechko
2008-03-10 15:20     ` Jan Kara [this message]
2008-03-10 22:46       ` [PATCH] quota: additional range checks and mem_dqblk updates?to " Andrew Perepechko
2008-03-11  3:16       ` Zhiyong Landen tian
2008-03-10 16:28 ` [PATCH] quota: additional range checks and mem_dqblk updates to " Jan Kara
2008-03-10 21:25   ` Andrew Perepechko
2008-03-12 17:21     ` [PATCH] quota: additional range checks and mem_dqblk updates?to " Jan Kara
2008-03-12 22:35       ` Andrew Perepechko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080310152059.GJ24873@duck.suse.cz \
    --to=jack@suse.cz \
    --cc=Andrew.Perepechko@Sun.COM \
    --cc=Johann.Lombardi@Sun.COM \
    --cc=Zhiyong.Tian@Sun.COM \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).