|
|
About
TODO
Blog
RSS
Old blog
Projects
Gallery
Notes
Sun, 20 Apr 2008
Real Jedi does not use kernel.
He writes new or extends existing, but it is from different serie.
This one will tell you how one will be able to build a distributed
and then parallel filesystem using POHMELFS.
Headline says it all: POHMELFS server will not be placed into kernel
so far, since it is already very fast (compared to in-kernel async NFS server),
and userspace programming is a bit easier and mostly because there is no
need to wait about 10 minutes while servers come up after ipmi reboot,
since they are located somewhere I do not know where and there is no posibility
to quickly reboot them by hand, so servers have lots of things to bring themself
up even if something was really screwed, like network boot, add here scsi probing,
possible fsck, initial bios memtest (8GB)...
So, planned POHMELFS server updates:
- PMCC - poor man
cache coherency protocol. Scheduled for the first half of the next week, btw.
- server extension to allow storing data on multiple devices (like creating mirroring),
first by saving data in several local directories (think about server, which mounted remote
dirs over POHMELFS or NFS, and local dirs).
- client/server extension to report lookup and readdir requests not only for local destination,
but also to different addresses, so that reading/writing could be done from different nodes
in parallel.
Somewhere at the beginning there is also a task to extend client to be able to
switch between different servers (if one goes down, client automatically reconnects to second
and so on).
And the most complex task is server parallelization, i.e. ability to have multiple
servers, which handle the same metadata, to work in parallel and be coherent. AFAIK, there
are no such (at least open) solutions, neither Lustre, nor PVFS2, nor Ceph,
nor glusterfs, nor whatever.
There are solutions to have master-slave setup (IIRC, Lustre works that way), Ceph has ability
to spread metadata between multiple servers, but they do not handle the same sets of objects,
so there is no metadata server redundancy.
So far I consider this as the most complex part, and I have not yet come to solution.
/devel/fs :: Link / Comments (0)
Please solve this captcha to be allowed to post (need to reload in a minute): 7 * 88
|