From: Pavel Machek <pavel@suse.cz>
To: Sage Weil <sage@newdream.net>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
ceph-devel@lists.sf.net
Subject: Re: Recursive directory accounting for size, ctime, etc.
Date: Tue, 5 Aug 2008 20:26:11 +0200 [thread overview]
Message-ID: <20080805182610.GD8380@ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.64.0806192313530.7379@cobra.newdream.net>
On Tue 2008-07-15 11:28:22, Sage Weil wrote:
> All-
>
> Ceph is a new distributed file system for Linux designed for scalability
> (terabytes to exabytes, tens to thousands of storage nodes), reliability,
> and performance. The latest release (v0.3), aside from xattr support and
> the usual slew of bugfixes, includes a unique (?) recursive accounting
> infrastructure that allows statistics about all metadata nested beneath a
> point in the directory hierarchy to be efficiently propagated up the tree.
> Currently this includes a file and directory count, total bytes (summation
> over file sizes), and most recent inode ctime. For example, for a
> directory like /home, Ceph can efficiently report the total number of
> files, directories, and bytes contained by that entire subtree of the
> directory hierarchy.
>
> The file size summation is the most interesting, as it effectively gives
> you directory-based quota space accounting with fine granularity. In many
> deployments, the quota _accounting_ is more important than actual
> enforcement. Anybody who has had to figure out what has filled/is filling
> up a large volume will appreciate how cumbersome and inefficient 'du' can
> be for that purpose--especially when you're in a hurry.
>
> There are currently two ways to access the recursive stats via a standard
> shell. The first simply sets the directory st_size value to the
> _recursive_ bytes ('rbytes') value (when the client is mounted with -o
> rbytes). For example (watch the directory sizes),
...
> Naturally, there are a few caveats:
>
> - There is some built-in delay before statistics fully propagate up
> toward the root of the hierarchy. Changes are propagated
> opportunistically when lock/lease state allows, with an upper bound of (by
> default) ~30 seconds for each level of directory nesting.
Having instant rctime would be very nice -- for stuff like locate and
speeding up kde startup.
> I'm extremely interested in what people think of overloading the file
> system interface in this way. Handy? Crufty? Dangerous? Does anybody
Too ugly to live.
What about new rstat() syscall?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2008-08-07 20:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 18:28 Recursive directory accounting for size, ctime, etc Sage Weil
2008-07-15 19:47 ` Andreas Dilger
2008-07-15 20:26 ` Sage Weil
2008-07-15 19:53 ` J. Bruce Fields
2008-07-15 20:41 ` Sage Weil
2008-07-15 20:48 ` J. Bruce Fields
2008-07-15 21:16 ` Sage Weil
2008-07-15 22:45 ` J. Bruce Fields
2008-07-15 21:44 ` Jamie Lokier
2008-07-15 21:51 ` Sage Weil
2008-07-15 21:56 ` Jamie Lokier
2008-08-05 18:26 ` Pavel Machek [this message]
2008-08-08 13:11 ` John Stoffel
2008-08-08 23:32 ` Sage Weil
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=20080805182610.GD8380@ucw.cz \
--to=pavel@suse.cz \
--cc=ceph-devel@lists.sf.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sage@newdream.net \
/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).