From: Ming Zhang <mingz@ele.uri.edu>
To: Ric Wheeler <ric@emc.com>
Cc: Grzegorz Kulewski <kangur@polcom.net>,
"Vladimir V. Saveliev" <vs@namesys.com>,
Sandeep Tyagi <sandeepktyagi@gmail.com>,
okuyamak@dd.iij4u.or.jp, reiserfs <reiserfs-list@namesys.com>
Subject: Re: fs_mark benchmark - update
Date: Mon, 29 Aug 2005 10:44:38 -0400 [thread overview]
Message-ID: <1125326679.5544.61.camel@localhost.localdomain> (raw)
In-Reply-To: <43131684.5040708@emc.com>
On Mon, 2005-08-29 at 10:07 -0400, Ric Wheeler wrote:
>
> Ming Zhang wrote:
>
> >On Mon, 2005-08-29 at 09:46 -0400, Ric Wheeler wrote:
> >
> >>It is also interesting to compare reiserfs vs ext3 when writing single
> >>threaded across the life span of a file system - reiserfs typically
> >>beats ext3 for most cases, but ext3 eventually catches up as the
> >>percentage used grows.
> >>
> >>
> >>
> >
> >this is interesting. looks like a file system aging problem. does this
> >because of the fragmentation?
> >
> >
>
> I think that this is because of the depth and size of the tree. We have
> very large volumes (up to 300GB) - if your file systems are smaller,
> then the degradation is not as large.
>
so will this be a scalability problem? all because we have 4KB block
size instead of using 64KB block size and pack small data using that
"tail" option?
500GB SATA is easy to buy and TB storage is not a dream at all. so this
will be a problem.
> >
> >what u mean new ext3?
> >
> >
> I should have said "new patches to ext3". At OLS, there was a talk
> describing this work - you can get the proceedings from linuxsymposium.org:
>
> http://www.linuxsymposium.org/2005/view_abstract.php?content_key=90
>
>
ic. thanks!
ming
next prev parent reply other threads:[~2005-08-29 14:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-25 12:01 fsync performance of reiser 4 Sandeep Tyagi
2005-08-25 13:23 ` Vladimir V. Saveliev
2005-08-29 12:32 ` Ric Wheeler
2005-08-29 12:37 ` Grzegorz Kulewski
2005-08-29 12:40 ` Ming Zhang
2005-08-29 13:25 ` Ric Wheeler
[not found] ` <43130DC1.20105@emc.com>
[not found] ` <1125322484.5544.23.camel@localhost.localdomain>
2005-08-29 13:46 ` fs_mark benchmark - update Ric Wheeler
2005-08-29 13:57 ` Ming Zhang
2005-08-29 14:07 ` Ric Wheeler
2005-08-29 14:44 ` Ming Zhang [this message]
2005-08-29 20:30 ` Hans Reiser
2005-08-29 21:15 ` Ric Wheeler
2005-08-29 21:29 ` Hans Reiser
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=1125326679.5544.61.camel@localhost.localdomain \
--to=mingz@ele.uri.edu \
--cc=kangur@polcom.net \
--cc=okuyamak@dd.iij4u.or.jp \
--cc=reiserfs-list@namesys.com \
--cc=ric@emc.com \
--cc=sandeepktyagi@gmail.com \
--cc=vs@namesys.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.