All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Masover <ninja@slaphack.com>
To: Alexey Polyakov <alexey.polyakov@gmail.com>
Cc: "Vladimir V. Saveliev" <vs@namesys.com>, reiserfs-list@namesys.com
Subject: Re: reiser4 resize
Date: Thu, 21 Sep 2006 02:48:49 -0500	[thread overview]
Message-ID: <451243E1.9050205@slaphack.com> (raw)
In-Reply-To: <b5d90b2a0609200039g70c40f5bvb374b5f15b42988d@mail.gmail.com>

Alexey Polyakov wrote:
> On 9/19/06, David Masover <ninja@slaphack.com> wrote:
> 
>> When I have over a
>> gig of RAM free (not even buffer/cache, but _free_), and am trying to
>> download anything over BitTorrent, even if it's less than 200 megs, the
>> disk thrashes so badly that the system is really only usable for web and
>> email.  Even movies will occasionally stall when this is happening, and
>> by "occasionally", I mean every minute or so.
> 
> Do you have this problem on plain vanilla + reiser4?

Yes.

Well, no.  My kernel is:

vanilla 2.6.17.13 on amd64

patches:
sk98lin 8.36, latest from the manufacturer
reiser4-for-2.6.17-3
my own patch that disables fsync and fdatasync

external modules, installed via Portage:
ALSA 1.0.11 driver, using snd_emu10k1 and all sorts of support stuff 
(OSS emulation, synth, etc)
nvidia driver, 1.0.8762

I've also been having a bit of instability issues, but only very rarely 
do these seem at all FS-related.  I'm overclocked a bit, and I can 
reliably crash my system by playing Neverball, Doom 3, or Quake 4 for 
several hours.  I strongly suspect this is either my overclocking or the 
nvidia drivers here.

However, I doubt anything I've done beyond vanilla+reiser4 is affecting 
this disk access issue, and I'm pretty much rock solid when I'm not 
playing a game.  I also have a close-to-identical machine nearby which 
is not overclocked, same kernel, same modules, everything except the 
nvidia driver, been rock solid for a year, no performance issues to 
speak of.  The main difference, other than graphics, is that the stable 
machine is using 21 gigs out of 72, whereas the unstable one (the one 
that's sluggish for BitTorrent) is using 279 gigs out of 350, and has 
been up to 320 or 330 at least before I started cleaning things out.

So I think we're down to two possibilities:  Either an update to Azureus 
has found a way to sync that I'm not aware of, or this is the behavior 
someone described where Reiser4 will attempt to find contiguous space to 
allocate, and continue searching and re-searching the same areas of the 
disk almost every write.  To be honest, I hope it's about syncing, 
somehow, because I'd much rather believe my disk isn't horrendously 
fragmented...

  parent reply	other threads:[~2006-09-21  7:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-19  1:12 reiser4 resize Jack Byer
2006-09-19 13:23 ` Vladimir V. Saveliev
2006-09-19 17:54   ` David Masover
2006-09-20  7:39     ` Alexey Polyakov
     [not found]       ` <op.tf52pansd4os1z@localhost>
2006-09-20  9:00         ` Alexey Polyakov
2006-09-21  7:30           ` David Masover
2006-09-21  7:49             ` Łukasz Mierzwa
2006-09-21  7:52             ` Łukasz Mierzwa
2006-09-21  7:48       ` David Masover [this message]
2006-09-20  1:09   ` Jack Byer
  -- strict thread matches above, loose matches on Subject: below --
2008-01-25 14:38 Reiser4 resize Oleg Osovitskiy
2008-01-30 20:40 ` Edward Shishkin
2008-03-02 22:39 No space left on rfs4 Christopher Sawtell
2008-03-03 20:59 ` Reiser4 resize John

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=451243E1.9050205@slaphack.com \
    --to=ninja@slaphack.com \
    --cc=alexey.polyakov@gmail.com \
    --cc=reiserfs-list@namesys.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.