linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Tomas <bzzz@tmi.comex.ru>
To: Ed Sweetman <ed.sweetman@wmich.edu>
Cc: linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: [RFC] extents support for EXT3
Date: Sat, 30 Aug 2003 13:09:32 +0400	[thread overview]
Message-ID: <m3u17zo6k3.fsf@bzzz.home.net> (raw)
In-Reply-To: <3F4FAFA2.4080202@wmich.edu> (Ed Sweetman's message of "Fri, 29 Aug 2003 15:55:14 -0400")


yes, you're correct. extents make sense for large files generally speaking.
having extents, it's simpler to implement delayed allocation, imho. delayed
allocation makes sense for all files. especially for temporary files (say,
.S files during make bzImage). this technique allows to avoid block allocation
at all for such files and make file's placement more contigoues.

I agree about system fs (/, /boot, /usr, /var), because most of files are
quite small and change rarely.

>>>>> Ed Sweetman (ES) writes:

 ES> Well, it appears that you need about 10+ blocks per extent to see any
 ES> noticable performance gain.  The problem is most files are not large
 ES> enough to achieve this.  Most range from a few kB to a couple mB. High
 ES> activity directories like /tmp and /usr deal mostly with numerous
 ES> small files.  Now the reason i bring this up is that extents basically
 ES> make your fs incompatible with any kernel not compiled with the patch,
 ES> which means if something bad happened and you needed to use a bootable
 ES> cdrom with some safety kernel, it wouldn't be that useful.  for such
 ES> small improvements, it doesn't seem worth the risk to make / or
 ES> directories like /tmp,/var,/usr,/boot,/lib etc, with extents.  The
 ES> files just dont get large enough to make performance gains worth more
 ES> than backward compatibility.

 ES> Now for media, like music and movies and such, this makes a lot of
 ES> sense. Files get large enough so that the block to extent use is very
 ES> high and the files aren't necessary to use the system.  extents are 5
 ES> seconds faster when md5summing a 622MB file than the same file written
 ES> without extents enabled.


 ES> I would not recommend using the patch for system directories only
 ES> because it leaves you with no way to rescue the system and does very
 ES> little in the way of performance for those directories. Ext3 is
 ES> backwards compatible with ext2, this patch seemingly breaks
 ES> that. Because of that it doesn't seem to be ext3 anymore, rather a one
 ES> way compatibility with ext3 with a purely large media bias.



  parent reply	other threads:[~2003-08-30  9:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-28  8:22 [RFC] extents support for EXT3 Alex Tomas
2003-08-28 17:22 ` [Ext2-devel] " Mike Fedyk
2003-08-29  5:55   ` Alex Tomas
2003-08-28 18:12 ` Ed Sweetman
2003-08-29  5:59   ` Alex Tomas
2003-08-29 15:28     ` Ed Sweetman
2003-08-29 15:38       ` Alex Tomas
2003-08-29 15:52         ` Ed Sweetman
2003-08-29 16:10           ` Alex Tomas
2003-08-29 16:16             ` Alex Tomas
2003-08-29 16:20             ` Ed Sweetman
2003-08-29 16:34               ` Alex Tomas
2003-08-29 17:49                 ` Ed Sweetman
2003-08-29 18:09                   ` Alex Tomas
2003-08-29 19:55                     ` Ed Sweetman
2003-08-29 21:39                       ` [Ext2-devel] " Mike Fedyk
2003-08-29 22:25                         ` Ed Sweetman
2003-08-29 23:17                           ` Mike Fedyk
2003-08-31 20:25                             ` Eric W. Biederman
2003-08-31 20:37                               ` Alex Tomas
2003-09-05 10:06                               ` Pavel Machek
2003-09-05 14:55                                 ` Eric W. Biederman
2003-08-30  9:09                       ` Alex Tomas [this message]
2003-08-30  8:55                   ` Alex Tomas
2003-08-30 10:13                   ` Alex Tomas
2003-08-28 22:00 ` Ramón Rey Vicente󮠒
2003-08-29  6:04   ` Alex Tomas
2003-08-29  9:55     ` Ramón Rey Vicente󮠒
2003-09-06  0:19 ` jw schultz
2003-09-06  6:09   ` Alex Tomas

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=m3u17zo6k3.fsf@bzzz.home.net \
    --to=bzzz@tmi.comex.ru \
    --cc=ed.sweetman@wmich.edu \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@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).