From: Wilco Baan Hofman <wilco@baanhofman.nl>
To: linux-kernel@vger.kernel.org
Subject: Re: RAID1 ramdisk patch
Date: Mon, 05 Sep 2005 09:40:29 +0200 [thread overview]
Message-ID: <431BF66D.4010804@baanhofman.nl> (raw)
In-Reply-To: <17179.40731.907114.194935@cse.unsw.edu.au>
Neil Brown wrote:
>On Monday September 5, wilco@baanhofman.nl wrote:
>
>
>>Hi all,
>>
>>I have written a small patch for use with a HDD-backed ramdisk in the md
>>raid1 driver. The raid1 driver usually does read balancing on the disks,
>>but I feel that if it encounters a single ram disk in the array that
>>should be the preferred read disk. The application of this would be for
>>example a 2GB ram disk in raid1 with a 2GB partition, where the ram disk
>>is used for reading and both 'disks' used for writing.
>>
>>Attached is a bit of code which checks for a ram-disk and sets it as
>>preferred disk. It also checks if the ram disk is in sync before
>>allowing the read.
>>
>>
>
>Hi,
> equivalent functionality is now available in 2.6-mm and is referred
> to as 'write mostly'.
> If you use mdadm-2.0 and mark a device as --write-mostly, then all
> read requests will go to the other device(s) if possible,.
> e.g.
> mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/ramdisk \
> --writemostly /dev/realdisk
>
> Does this suit your needs?
>
> You can also arrange for the write to the writemostly device to be
> 'write-behind' so that the filesystem doesn't wait for the write to
> complete. This can reduce write-latency (though not increase write
> throughput) at a very small cost of reliability (if the RAM dies, the
> disk may not be 100% up-to-date).
>
>NeilBrown
>
>
>
I was looking for that (but couldn't find it)..
At this point I don't see why it wouldn't, if that also syncs from the
partition then it's basically the same functionality, but written from a
different perspective.
To use it I'll have to deviate from stock linux and use a non-packaged
mdadm, but that is better than applying my patch every kernel update ;-)
Thanks, I'll look into it.
Wilco Baan Hofman
next prev parent reply other threads:[~2005-09-05 7:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-05 0:46 RAID1 ramdisk patch Wilco Baan Hofman
2005-09-05 1:27 ` Neil Brown
2005-09-05 7:40 ` Wilco Baan Hofman [this message]
2005-11-16 13:36 ` segfault mdadm --write-behind, 2.6.14-mm2 (was: Re: RAID1 ramdisk patch) Sander
2005-11-16 22:20 ` Andrew Morton
2005-11-16 23:08 ` Neil Brown
2005-11-17 7:50 ` Sander
2005-11-17 10:12 ` Sander
2005-11-17 10:15 ` Sander
2005-11-21 23:07 ` Please help me understand ->writepage. Was " Neil Brown
2005-11-21 23:30 ` Jeff Garzik
2005-11-21 23:51 ` Andrew Morton
2005-11-22 3:12 ` Neil Brown
2005-11-22 3:47 ` Andrew Morton
2005-11-22 10:34 ` Sander
2005-11-24 5:41 ` Please help me understand reiser4_writepage. " Neil Brown
2005-11-22 12:00 ` Please help me understand ->writepage. " Anton Altaparmakov
2005-11-24 5:29 ` Neil Brown
2005-11-18 14:18 ` segfault mdadm --write-behind, 2.6.14-mm2 Vladimir V. Saveliev
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=431BF66D.4010804@baanhofman.nl \
--to=wilco@baanhofman.nl \
--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