| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
| Months | ||
|---|---|---|
| Jan | Feb | Mar |
| Apr | May | Jun |
| Jul | Aug | Sep |
| Oct | Nov | Dec |
About
TODO
Blog
RSS
Old blog
Projects
Gallery
Notes
Thu, 26 Jul 2007
Exporting local nodes in the distributed storage has entered testing stage.
Now it is possible to export local storage (block device) to remote system.
So far it was only possible to use userspace application to be a target, but now there is a kernel target too.
It is faster. It allows to build tree structures of the nodes to remove
single points of failure. It allows to simplify configuration. It allows
to simpler implement recovery (like reconnect, which is next step before
first release). This is pretty simple, since the whole infrastructure was already there.
As I said, next task is initial failover support - so far I only plan to add
reconnect on error. Then I will either release first version, or (likely) will add
redundancy algo (simple mirror).
And of course testing... I will start running heavy benchmark (like iozone
or any other from my great filesystem contest
benchmarks) after local node exporting is tested.
And I again did not move to development shop. Well, eventually...
/devel/dst :: Link / Comments (0)
Linux sucks.
Please tell me how is it ever possible in 21 century
on two-core system with 3.4 Ghz each and two gigs of ram
to stop playing music when system runs recursive chown
on a huge dir?:
top - 14:36:57 up 21:39, 10 users, load average: 0.91, 0.32, 0.12 Tasks: 151 total, 2 running, 149 sleeping, 0 stopped, 0 zombie Cpu(s): 1.7%us, 2.0%sy, 0.0%ni, 34.2%id, 62.1%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2075052k total, 1581176k used, 493876k free, 645032k buffers Swap: 1951856k total, 0k used, 1951856k free, 434852k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7403 root 20 0 3988 952 632 R 3 0.0 0:04.04 chown 7366 s0mbre 20 0 27884 3776 2904 S 1 0.2 0:03.74 mplayerThis is default FC7 installation with the most recent kernel 2.6.22.1-27.fc7.
Crap.
/devel/other :: Link / Comments (8)
Quotation of the day.
Chris Mason wrote:
> Definitely, and I'm glad you are. You haven't converted me yet, butP.S. Both Chris Mason and Jens Axboe work in Oracle, Jens is block layer maintainer. Talk is about how to map data to disk (file offset to block number, flags, sub-page blocks) and to replace buffer_heads with new extent based tree (rb-tree is used, although that can be slow, since requires locking, multidimensional trie similar to judy array used in unified socket storage allows to use RCU protection).
> I look forward to finding the best ideas from our two approaches when
> the patches are further along (ext2 port of fsblock coming along, so
> we'll be able to have races soon :P).
I'm sure we can find some river in Cambridge, winner gets to throw Axboe in.
Likely Jens Axboe worked closely with of this much-hated buffer_heads :)
/devel/other :: Link / Comments (0)