All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Drokin <green@namesys.com>
To: Manuel Krause <manuel.krause@mb.tu-ilmenau.de>
Cc: reiserfs-list <reiserfs-list@namesys.com>
Subject: Re: Copy time comparison 2.4.20-pre6 <-> 2.4.19+data-logging (was:Compatibility of  current 2.4.19.pending ...)
Date: Thu, 19 Sep 2002 20:01:30 +0400	[thread overview]
Message-ID: <20020919200130.A18305@namesys.com> (raw)
In-Reply-To: <3D89F2AF.3080806@mb.tu-ilmenau.de>

Hello!

On Thu, Sep 19, 2002 at 05:52:15PM +0200, Manuel Krause wrote:

> >>Yes, it fits. I know that problem with this RAM based test. Though I may 
> >>increase the testing directory a bit closer to the OOM limit, having 
> >>512MB available.
> >No, this is not enough of course since some data will remain unflushed and
> >amount of such data is relatively big compared to total amount of data.
> And if the participating filesystems are umounted after writing the data?

Then it is ok of course. All fs' buffers are flushed on umount.

> >But here is another warning:
> >I presume before each copy test is done, /mnt/beta/z.Backup.3 is removed
> >completely and /mnt/beta is unmounted and mounted back, also
> >between sevetral writing attempts (And during these attempts of course)
> >no other processes can write to to this FS.
> These clauses are both true and apply to the dd tests, too. Mmh, except 
> for the case when /mnt/beta/z.Backup.3 or testfile.zero were the source 
> to be copied/dd'ed... There haven't been overwrites or other writes to 
> the disk during the testsets.
Ok, good.

> >I presume you earased /mnt/beta/testfile.zero between tests and executed
> >sync.
> I umounted the partition and mounted it back. I thought that would be 
> the right action to avoid what you describe in the following:

Yes.

> >I thought that original data is residing on another filesystem on another 
> >disk.
> >If originally you vere copying data from one disk to the same disk, just
> >another partition, then thisis just lots of seeks.
> Thanks for these reminders. Originally I wanted to copy data from one 
> disk to another and on the way capture the timings to compare the 
> throughput... Then you pointed me to re-check pure reads and pure writes 
> mainly to make sure the writes were not read-speed bound and to compare 
> this behaviour on -pre6 and -pre7.

Originally I was mostly interested in reads from source fs, not the one
where you have copied the data (though that one is also might be useful).

Ok, thank you for lots of testing.

Bye,
    Oleg

  reply	other threads:[~2002-09-19 16:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-12  0:24 Compatibility of current 2.4.19.pending patchset with old data-logging?? Manuel Krause
2002-09-12 13:28 ` newbie how to darren
2002-09-12 14:37   ` Hans Reiser
2002-09-12 15:12     ` Guillermo Torreiro
2002-09-12 21:30 ` Copy time comparison 2.4.20-pre6 <-> 2.4.19+data-logging (was:Compatibility of current 2.4.19.pending ...) Manuel Krause
2002-09-13  7:37   ` Oleg Drokin
2002-09-13 23:07     ` Manuel Krause
2002-09-14  9:02       ` Oleg Drokin
2002-09-17  0:53         ` Manuel Krause
     [not found]         ` <3D867C14.5060404@mb.tu-ilmenau.de>
2002-09-17  6:33           ` Oleg Drokin
2002-09-17 13:56             ` Manuel Krause
2002-09-17 14:00               ` Oleg Drokin
2002-09-17 17:39                 ` Manuel Krause
2002-09-18  5:20                   ` Oleg Drokin
2002-09-19  1:14                     ` Manuel Krause
2002-09-19  6:34                       ` Oleg Drokin
2002-09-19 15:52                         ` Manuel Krause
2002-09-19 16:01                           ` Oleg Drokin [this message]
2002-09-23  0:36                             ` Manuel Krause

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=20020919200130.A18305@namesys.com \
    --to=green@namesys.com \
    --cc=manuel.krause@mb.tu-ilmenau.de \
    --cc=reiserfs-list@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.