JLRG> 1- There is no need to use parity map for the RAID 1/10/5/6. Usually
JLRG> the impact is small, but it can be noticeable in busy servers.
EF> I don't notice it.
JLRG> When there is a crash, the time to rebuild the raid < 1min?
I said I didn't notice an impact. Of course I do notice a massive
On Wed, Sep 14, 2016 at 03:16:13PM +, Eduardo Horvath wrote:
> On Wed, 14 Sep 2016, Edgar Fu? wrote:
>
> > > 2- In scattered writes contained in a same slice, it allows to reduce
> > > the number of writes. With RAID 5/6 there is a advantage, the parity
> > > is written only one time for sever
Holland, thank you for your answers.
On Sat, Sep 10, 2016 at 7:41 PM, David Holland wrote:
> On Fri, Sep 09, 2016 at 11:09:49PM +0200, Jose Luis Rodriguez Garcia wrote:
>
> It sounds like you've already decided what layer it appears in, if
> it's going to be used as a block device.
Is there other
On Wed, 14 Sep 2016 13:54:34 +0200, Edgar Fuß wrote:
>> 4- Faster synchronous writes.
> Y E S.
> This is the only point I fully aggree on. We've had severe problems with
> brain-dead software (Firefox, Dropbox) performing tons of synchronous 4K
> writes (on a bs=16K FFS) which nearly killed us un
>> 1- There is no need to use parity map for the RAID 1/10/5/6. Usually
>> the impact is small, but it can be noticeable in busy servers.
>I don't notice it.
When there is a crash, the time to rebuild the raid < 1min?
...
>rather large. A segment should match a slice (or a number of them)
>I would
On Wed, 14 Sep 2016, Edgar Fu? wrote:
> > 2- In scattered writes contained in a same slice, it allows to reduce
> > the number of writes. With RAID 5/6 there is a advantage, the parity
> > is written only one time for several writes in the same slice, instead
> > of one time for every write in the
On Wed, Sep 14, 2016 at 01:54:34PM +0200, Edgar Fuß wrote:
> [...]
> I would suppose LFS to perform great on a RAIDframe. Isn't Manuel Bouyer
> using this in production?
No, I played with LFS at some point but I never used it in production.
--
Manuel Bouyer
NetBSD: 26 ans d'experience fer
I'm using a 12TB RAIDframe Level 5 RAID (4+1 discs) in production.
There are 150 people's home directories and mail on FFFs file systems on it.
> 1- There is no need to use parity map for the RAID 1/10/5/6. Usually
> the impact is small, but it can be noticeable in busy servers.
I don't notice it.
On Sat, Sep 10, 2016 at 4:18 PM, Thor Lancelot Simon wrote:
> On Fri, Sep 09, 2016 at 11:09:49PM +0200, Jose Luis Rodriguez Garcia wrote:
>> B- It can use the buffer cache for avoid read/write cycles, and do
>> only writes if the data to be read is in memory.
>
> I'd stay more focused on avoiding
On Fri, Sep 09, 2016 at 11:09:49PM +0200, Jose Luis Rodriguez Garcia wrote:
> This is a continuation of the thread Is factible to implement full
> writes of stripes to raid using NVRAM memory in LFS.
> http://mail-index.netbsd.org/tech-kern/2016/08/18/msg020982.html
>
> I want to discuss in w
On Fri, Sep 09, 2016 at 11:09:49PM +0200, Jose Luis Rodriguez Garcia wrote:
>
> The proposed layer must support:
>
> A- It must be able to obtain the raid configuration of the raid device
> backing the writeback cache. If it is a RAID 0/1 it will cache
> portions of the size of the interleave. If
This is a continuation of the thread Is factible to implement full
writes of stripes to raid using NVRAM memory in LFS.
http://mail-index.netbsd.org/tech-kern/2016/08/18/msg020982.html
I want to discuss in what layer must be located a write back-cache. It
will be used usually for for raid configur
12 matches
Mail list logo