From: Nathan Scott <nathans@sgi.com>
To: Steve Lord <lord@sgi.com>
Cc: hch@ns.caldera.de, Alan Cox <alan@lxorguk.ukuu.org.uk>,
"Gonyou, Austin" <austin@coremetrics.com>,
narancs@narancs.tii.matav.hu, linux-xfs@oss.sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: XFS to main kernel source
Date: Fri, 21 Sep 2001 15:42:00 +1100 [thread overview]
Message-ID: <20010921154159.H416300@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <adilger@turbolabs.com> <200109210325.f8L3PKi20270@jen.americas.sgi.com>
In-Reply-To: <200109210325.f8L3PKi20270@jen.americas.sgi.com>; from lord@sgi.com on Thu, Sep 20, 2001 at 10:25:20PM -0500
hi,
On Thu, Sep 20, 2001 at 10:25:20PM -0500, Steve Lord wrote:
> > On Sep 20, 2001 16:31 -0500, Steve Lord wrote:
> > > XFS quotas are transactional, when space is added to a file the quota is
> > > adjusted in the same transaction. It is fairly hard to do this without your
> > > own quota code.
> >
> > Actually not. The quotas in ext3 are transactional as well. It's just
> > that the "ext3" journal layer allows nested transactions, so it is possible
> > to start a write transaction, call into the journal code which calls back
> > into the ext3 write code to start a nested transaction on the journal file
> > (i.e. it is in the same transaction as the initial write), and then the
> > initial write completes.
>
> OK, good point, but doing a major rewrite of XFS to use a different
> transaction mechanism is not really on the cards, plus we have on disk
> compatibility with the Irix version to consider.
>
XFS also uses quite a different _model_ of quota, and it is
tightly integrated into XFS (by its very nature). There
are a number of issues that it attempts to address, and in
particular it works around the inherent problems of the
traditional quotacheck/mount/quotaon/quotaoff model (ie. the
BSD quota model which the Linux VFS also uses, and which was
used in IRIX for the EFS filesystem).
Its simply different, there are advantages and disadvantages
of each way, but XFS is particularly aimed at scalability,
and the desire to never have to run quotacheck(8) on large
filesystems was one of the issues which the original design
aimed to address.
So XFS quota should be a non-issue. I have had discussions
with Jan Kara and Alan in the past about how to most cleanly
integrate it with their (new) VFS quota, and they seem happy
with the design we collectively came up with (its slightly
different to the one in both the XFS patch and Alan's patch
at the moment).
cheers.
--
Nathan
next prev parent reply other threads:[~2001-09-21 4:42 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-20 20:07 Gonyou, Austin
2001-09-20 20:14 ` Alan Cox
2001-09-20 20:16 ` Steve Lord
2001-09-20 20:25 ` Alan Cox
2001-09-20 20:26 ` Christoph Hellwig
2001-09-20 21:31 ` Steve Lord
2001-09-21 3:12 ` Andreas Dilger
2001-09-21 3:25 ` Steve Lord
2001-09-21 4:42 ` Nathan Scott [this message]
2001-09-21 5:58 ` Christoph Hellwig
2001-09-21 8:40 ` Narancs v1
2001-09-21 14:19 ` Alexander Viro
2001-09-21 14:45 ` Steve Lord
2001-09-20 20:40 ` Alexander Viro
2001-09-21 18:03 ` Steve Lord
2001-09-20 20:29 ` Horst von Brand
2001-09-20 20:50 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2001-11-21 23:32 [PATCH] Remove needless BKL from release functions David C. Hansen
2001-11-22 10:12 ` Oliver Neukum
2001-11-22 12:11 ` Christoph Hellwig
2001-11-22 12:30 ` Horst von Brand
2001-11-22 13:05 ` Christoph Hellwig
2001-11-23 9:44 ` Rick Lindsley
2001-11-23 10:10 ` Oliver.Neukum
2001-11-23 10:47 ` Christoph Hellwig
2001-11-23 11:24 ` Oliver Neukum
2001-11-26 17:46 ` David C. Hansen
2001-11-26 19:41 ` Flavio Stanchina
2001-11-26 19:53 ` David C. Hansen
2001-11-23 12:08 ` Rick Lindsley
2001-11-06 20:04 [PATCH] lp.c, eexpress.c jiffies cleanup Tim Schmielau
2001-11-06 21:15 ` Andreas Dilger
2001-11-06 21:37 ` Philip Blundell
2001-11-07 0:10 ` Andreas Dilger
2001-11-06 23:58 ` Tim Hockin
2001-09-20 18:12 XFS to main kernel source Narancs v1
2001-09-20 20:02 ` Alan Cox
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=20010921154159.H416300@wobbly.melbourne.sgi.com \
--to=nathans@sgi.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=austin@coremetrics.com \
--cc=hch@ns.caldera.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=lord@sgi.com \
--cc=narancs@narancs.tii.matav.hu \
/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
all inboxes | Powered by JetHome®