From: "Circuitsoft Development" <circuitsoft.devel@gmail.com>
To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Extended Volume Manager API
Date: Mon, 1 May 2006 00:26:05 -0500 [thread overview]
Message-ID: <64b292120604302226i377f1c37qd33db36693ea1871@mail.gmail.com> (raw)
Question:
How hard would it be to implement a volume manager with an extended
API? I want to write a tightly-integrated volume manager/distributed
lock manager to arbitrate lock-free, atmoic read/compare/write
operations with other computers on the network. Also, I have a need to
have this API available to user-space applications. How would I do
this?
Details follow, if you're curious.
The idea is to make a distributed filesystem that won't hiccup when a
client node crashes. I've decided to implement all the gritty work in
the volume manager, and just design the filesystem to take advantage
of it.
Having done my own tests, I've determined that a 5msec timeout to
determine if a host has crashed would be appropriate. (My test was
basically looking at ping time over a saturated network - averaged
about 600 microseconds, topped at 3msec over 10 minutes) I figure that
5msec timeout won't add any noticeable lag to the volume manager, as
most disk seek times are in that range.
Anyway, we basically have the volume manager asking around for
everyone else on the network, to see if they have a particular area
locked. If so, wait for it to be unlocked. If not, record and
broadcast the lock, then do the atomic read/compare/write operation
while locked, and unlock before we return to the client (filesystem).
I need the API to this code to be available to userspace due to an
application that I cannot mention because of an informal NDA.
Thank you,
- Alex Austin, Circuitsoft Computer Services
"From Windows to MacOS, and the Linux in between"
next reply other threads:[~2006-05-01 5:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-01 5:26 Circuitsoft Development [this message]
2006-05-01 7:02 ` Valdis.Kletnieks
[not found] ` <64b292120605010759h4d9c74d7s717d125018ab95d3@mail.gmail.com>
2006-05-01 20:10 ` Fwd: " Circuitsoft Development
2006-05-02 12:42 ` Rik van Riel
[not found] ` <64b292120605062123gdb302d2g201fa59e93bc6a25@mail.gmail.com>
2006-05-08 21:17 ` Fwd: " Circuitsoft Development
2006-05-08 21:51 ` Lars Marowsky-Bree
2006-05-09 7:24 ` Circuitsoft Development
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=64b292120604302226i377f1c37qd33db36693ea1871@mail.gmail.com \
--to=circuitsoft.devel@gmail.com \
--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
all inboxes | Powered by JetHome®