[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gluster-devel] Request for "read-only" translator
From: |
Steffen Grunewald |
Subject: |
Re: [Gluster-devel] Request for "read-only" translator |
Date: |
Sat, 30 Jun 2007 17:01:21 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Sat, Jun 30, 2007 at 11:41:19AM +0400, Raghavendra G wrote:
> Hi Steffen,
> Sorry there was A mistake in my reply. The Unify schedulers cannot schedule
> based on whether a sub-volume is read-only or not. Hence when a new file
> creation operation comes, the scheduler _cannot_ neglect the read-only
> subvolumes for creating the file. There is a fairly good chance that the
> file creation operation be scheduled on a read-only subvolume which ofcourse
> will fail.
That's a pity.
Please reconsider this: Imagine a storage cluster mainly used for "archival
of data on spinning media". In such a case, one would set up a round-robin
scheduler to fill the storage devices (bricks) one by one, and one would
"freeze" full bricks by setting them read-only so modification will be no
longer possible. I think such a behaviour would make sense.
So here's the setup again:
> >> brick1a
> >> > AFR (mirror) > readonly
> >> brick1b \
> >> |
> >> brick2a |
> >> > AFR (mirror) > readonly |
> >> brick2b > unify round-robin
> >> |
> >> brick3 (AFR if I'm paranoid) | - set to read-only when full
> >> brick4 (can be AFR) | - ...
> >> brick5 (can be AFR) /
> >> ...
Cheers,
steffen