Planet FreeBSD Summer of Code 2007

Ivan Voras: VirtualBox

2007-10-15T19:14:36+00:00

I’m trying out VirtualBox VM software and so far I’m pleased. It seems to have significantly better performance then VMWare Server, and it’s maybe better than VMWare ESX 3:

INDEX VALUES
TEST BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700.0 6479416.5 555.2
Double-Precision Whetstone 55.0 1636.4 297.5
Execl Throughput 43.0 355.2 82.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 71113.0 179.6
File Copy 256 bufsize 500 maxblocks 1655.0 29474.0 178.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 114875.0 198.1
Pipe Throughput 12440.0 244627.7 196.6
Pipe-based Context Switching 4000.0 9561.1 23.9
Process Creation 126.0 926.1 73.5
Shell Scripts (8 concurrent) 6.0 23.0 38.3
System Call Overhead 15000.0 117599.8 78.4

===== FINAL SCORE 122.1

(these results are comparable with the VMWare Server benchmark from a few days ago; the VMWare ESX benchmark in the same post was done on a slower hardware)

I’s only shortcoming is that it doesn’t seem to support “background” VM instances If that gets implemented, VirtualBox could become the best very best VM choice for FreeBSD.

There were some noncommittal talks about maybe porting VirtualBox to FreeBSD (in “host” mode) so the product is becoming very exciting.

Update: It might be fast but apparently it doesn’t work yet. The guest OS doesn’t survive a buildworld. After some time the kernel complained four times about unexpected eflags in sigreturn (like 0×80283), and I had four unrelated processes stuck in a tight CPU-using loop.

Ivan Voras: Unionfs patches are in the tree!

2007-10-14T19:30:06+00:00

Finally!

Unionfs was unusable (at least for me) without these patches and today they were finally committed to 8-CURRENT. They should be MFC-ed to 7-STABLE after a week.

(If you didn’t know 7-STABLE was branched, then—surprise!)

Ivan Voras: Bounties?

2007-10-07T22:44:56+00:00

I’m wondering how open are FreeBSD users to the idea of providing funding for some FreeBSD-specific development. I’m specifically interested about “bounties” such as those from rsync.net for certain specific projects. The FreeBSD Foundation always accepts donations, but this is something different and more targeted.

Let’s give an example (nothing definite right now, no obligations, even the main developer(s) aren’t contacted about the idea): are there any people or organizations that would fund BLUFFS? The motivation is clear: a clean journaling file system compatible with UFS. Though ZFS is nice, it’s still not stable enough (and requires so much memory it’s not suitable for smaller machines) and softupdates is in bad shape anyway.

If you’re interested, have an idea or actually anything to contribute to this topic, please post a reply.

Ivan Voras: How slow is VMWare (Server)?

2007-09-29T21:47:43+00:00

VMWare is slow. But how slow is it? Here’s two runs of benchmarks/unixbench on the same machine, first in a VMWare guest under VMWare Server 1.0 on Windows XP, the second under the native OS on the same machine.

Here are the results on VMWare:

INDEX VALUES
TEST BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700.0 6330202.6 542.4
Double-Precision Whetstone 55.0 1606.8 292.1
Execl Throughput 43.0 468.4 108.9
File Copy 1024 bufsize 2000 maxblocks 3960.0 36722.0 92.7
File Copy 256 bufsize 500 maxblocks 1655.0 11696.0 70.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 49643.0 85.6
Pipe Throughput 12440.0 95945.5 77.1
Pipe-based Context Switching 4000.0 21320.3 53.3
Process Creation 126.0 1209.9 96.0
Shell Scripts (8 concurrent) 6.0 1.0 1.7
System Call Overhead 15000.0 47093.0 31.4

===== FINAL SCORE 70.1

And here on the raw hardware:

INDEX VALUES
TEST BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700.0 6467105.1 554.2
Double-Precision Whetstone 55.0 1633.7 297.0
Execl Throughput 43.0 2030.9 472.3
File Copy 1024 bufsize 2000 maxblocks 3960.0 63783.0 161.1
File Copy 256 bufsize 500 maxblocks 1655.0 57489.0 347.4
File Copy 4096 bufsize 8000 maxblocks 5800.0 53476.0 92.2
Pipe Throughput 12440.0 930715.9 748.2
Pipe-based Context Switching 4000.0 204248.8 510.6
Process Creation 126.0 5373.3 426.5
Shell Scripts (8 concurrent) 6.0 563.7 939.5
System Call Overhead 15000.0 720641.0 480.4

===== FINAL SCORE 387.4

Both guests are FreeBSD 7-CURRENT with debugging disabled. The results are not 100% comparable since the VMWare image was run without SMP, but on this benchmark, SMP positively influences only “shell scripts” results (parallel execution) – other results are either comparable, or negatively influenced by SMP (the CPU is a dual-core Athlon 64, i386 mode).

Make your own conclusions, but I consider the IO and context switch performance so bad they’re making the whole system unusable in production (at least where performance is important).

Update:

In defense of VMWare I’ve run unixbench on VMWare ESX3 server (though on a system not at all comparable to the one in above benchmarks – a 3 GHz Xeon from the NetBurst era, running 6.2-RELEASE as a guest) and the results are better:

INDEX VALUES
TEST BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700.0 5113310.0 438.2
Double-Precision Whetstone 55.0 935.0 170.0
Execl Throughput 43.0 555.5 129.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 55662.0 140.6
File Copy 256 bufsize 500 maxblocks 1655.0 17818.0 107.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 66604.0 114.8
Pipe Throughput 12440.0 132556.6 106.6
Pipe-based Context Switching 4000.0 18074.1 45.2
Process Creation 126.0 1414.9 112.3
Shell Scripts (8 concurrent) 6.0 130.7 217.8
System Call Overhead 15000.0 62919.9 41.9

===== FINAL SCORE 121.2

I still wouldn’t use it where performance is important, but at least these results look half-usable. The major improvement seems to be in context switching and parallel execution.

Second update:

Here’s the same setup as in the first VMWare Server benchmark (same machine, Windows XP host, 7-CURRENT), with QEmu+kqemu (kernel+user code acceleration):

TEST BASELINE RESULT INDEX

Dhrystone 2 using register variables 116700.0 5456588.4 467.6
Double-Precision Whetstone 55.0 1492.1 271.3
Execl Throughput 43.0 166.5 38.7
File Copy 1024 bufsize 2000 maxblocks 3960.0 13744.0 34.7
File Copy 256 bufsize 500 maxblocks 1655.0 4426.0 26.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 23832.0 41.1
Pipe Throughput 12440.0 23079.7 18.6
Pipe-based Context Switching 4000.0 2159.5 5.4
Process Creation 126.0 409.8 32.5
Shell Scripts (8 concurrent) 6.0 8.6 14.3
System Call Overhead 15000.0 9728.4 6.5

===== FINAL SCORE 33.3

Compared to this, VMWare server doesn’t look bad at all

Andrew Turner: FreeBSD update front end update

2007-09-22T10:46:40+00:00

My work towards creating a front end for freebsd-update is progressing. I have it at the point where it is exchanging dummy information about the patches on a machine. I've added signal handlers to shut down the back end correctly. The network code is fixed when the back end attempts ...

Andrew Turner: FreeBSD update front end first cut

2007-09-22T10:46:40+00:00

I've managed to get my front and back ends talking to each other. The front-end is written in Python. It loads a Glade file and uses that to generate the window to display. To run it you need a copy of //depot/projects/soc2007/andrew-update/ from perforce. Run 'make' to build it. Next, from ...

Alexey Tarasov: Time to stop relaxing

2007-09-12T12:28:27+00:00

About half of month I was doing nothing (actually vacations were planned, but they shifted once and shifted totally away at second time :)) I gave my second testing computer to brother, so I’m waiting when ordered notebook will come to doors of my home to continue developing.

There are several major tasks to perform:

1. Check why gziped version of modules are not loaded correctly (rc and forth scripts e.g. loaded correctly). I’ve unwinded call stack from interact() to working with file systems, it seems there is no nothing criminal, but non-compressed versions of modules are not loaded after first 512 bytes read by file_read(). May be I’ve made somewhere incorrect define of macro.

2. To implement directory listing (parse html result of server-reply). Main purpose to use same code for different listing types (detect numbers anf filenames between tags without actual parsing of html). After first view – this task seems solvable.

3. To comment more accurately commits, that were changing libstand. May be I’ll add also another function there strnstr(), which behaviour is “emulated” now in not very good fashion in pxe_http module with usage of strstr() and manual adding of zero byte at end of readed from socket data.

4. Work a little bit with assembler source. There is now unused code here and there is working, but may be not very correct ISR here. So, change it. Also, PXE call trap is duplicated – so there may be small optimization.

5. Added to loader functions must be revised (some of them really useless, after testing is completed). Comment them.

6. Write more solid documentation. And upgrade existing in some parts.

I hope, I’ll start working at the end of week. After completing of this tasks earlier mentioned telnet client module will be started (may be this will need to make PXE sockets API more similar to common sockets, then it’ll be possible to use common telnet client code, but without advanced terminal settings and signals support).

Ivan Voras: finstall alpha version

2007-08-29T08:17:01+00:00

As some of you might now, I’ve been working on a GUI installer for FreeBSD as a Google Summer of Code 2007 project that would one day, with some luck, replace the aging sysinstall. The SoC is now officially over and it’s time to make a public release of what’s been done so far.

But first, I’d like to write a bit about the project itself. Here are some of the more important ideas planned for the project, in no particular order:

Make a modern installer for a modern FreeBSD system, with support for advanced features not present in sysinstall.

Make the installer run directly of a FreeBSD Live CD

Separate the installer (as a tool) into the front-end and the back-end.

Make both the front-end and the back-end extensible enough so new features can be easily added.

Make the front-end and the back-end interchangeable so people can write their own replacements.

Make the back-end network-aware so it can support network (remote) installations. Use a service announcement and configuration technology such as Zeroconf.

Eventually, make the back-end a part of FreeBSD base to be used for regular system configuration.

I’m happy to say the project is going on nicely, and that I’ve created infrastructure that can support the above features (as well as some other goodies discussed at the recent BSDCan). The project itself is hosted in the FreeBSD’s Perforce depot. It consists of three parts / subprojects:

installer – the installer application, created in Python with PyGTK as the GUI library

pybackend – the backend daemon. For speedy coding, it was also implemented in Python, but if the project gains popularity, a C version that can be included in FreeBSD base system is planned.

makeimage – a Python script that creates a LiveCD ISO image with the installer. It can be customized to produce generic FreeBSD LiveCDs.

The back-end is a mostly stateless XML-RPC server that provides two kind of services: synchronous RPC calls and asynchronous “jobs” (that can take a long time and have progress checking infrastructure). The front-end is a modular PyGTK application that provides the user interface and uses the back-end for all “real” work.

I’ve created an ISO image with the installer embedded in it that can be used primarily for testing. The LiveCD is a fully working FreeBSD 7-CURRENT installation (i386) with X.Org 7.0, Xfce 4.2 desktop environment, Firefox, Thunderbird and a couple of supporting utilities. The image was built with mtune=generic CPU optimizations (pentium-m, pentium-4 and others). The installer version included in this LiveCD is a test version, more like a technology preview than a usable application. It can only install the system on a blank, unpartitioned drive and has only been tested on VMWare so far. I’ve disabled features that I know will not work (yet) but there’s still a chance there are bugs in the existing/enabled options.

Speaking of bugs, the overall state of FreeBSD 7-CURRENT is not very stable right now, and there are several known bugs and panics that will hopefully be resolved before 7.0. The system on the LiveCD (that is also used for the new installation) is not the “official” system that can be downloaded from FreeBSD source repositories. It contains several local patches I’ve made (or found from other developers and applied) to resolve some of the bugs and instabilities. I’ve submitted the patches to re@ some time ago, but they have still not been applied to the official source tree. Even so, there are several more-or-less known problems in the kernel I’m using, so you can expect random panics (you can imagine it’s hard do develop something like this with random panics happening all the time ). In particular, the LiveCD kernel might panic during the last phase (configuration), which is a problem I currently can’t solve.

I think that’s all that needs to be said. Download the installer image, try it out and see for yourself how it works. As I’ve said, there’s still a lot to be done and some planned features are not present in this release – but have fun trying it out. I won’t make an official announcement on current@ because I think it’s too early for that, so if you have any suggestions or questions you can post them as comments to this blog post. Please post both successes and failures (but keep the reports short ). (n.b. I’ll delete all comments that don’t have something useful to say, e.g. “I’m downloading it and I’ll try it tomorrow” type of posts).

P.S. If you don’t want to try it yet, I’ve created several screenshots of finstall.

Ivan Voras: RAID flash

2007-08-24T11:00:24+00:00

I’ve just had a sort-of shock about how cheap the USB flash drives have become (vs. how pricey they used to be a long time ago). I didn’t look at their prices for a long time (since I didn’t need any new flash drives) so I was pleasantly surprised with the per/MB prices that have become “normal”. On the other hand, capacity of consumer USB drives hasn’t gone up much – it seems 8 GB is the top of the range now, and speed is still not great – it seems 8-10 MB/s is the norm. But it’s relatively cheap technology now.

It seems that now is a good time to start experimenting with flash memory even in production, especially where seek times are important (flash drives have no seek latency that’s present in mechanical drives). Having no seek time has a nice side-effect when drives are used in RAID1 with gmirror, which can be configured to split large read requests over the mirrored drives. With mechanical drives this mode couldn’t produce significant performance because the drive heads still needed to seek through the unread portions (for sequential requests) but the situation is ideal for seek-less drives.

I think the ideal solution here would be RAID 1+0 with four drives. Admittedly, this would only give 16 GB of storage space (if each individual drive is 8 GB), but the (read) performance should scale linearly to ~~ 40 MB/s (once it would double in gmirror/RAID1, then again in gstripe/RAID0), which is decent. 16 GB is relatively small, but flash memory is much cheaper than server memory (e.g. FB-DIMM) and most databases are relatively small, so it might not be affordable to keep the whole database in RAM any more.

Only one question remains now – how many IOPS can be had from flash memory (unconfirmed information says: around 2000), and does having all flash drives on the same host USB bus (e.g. one USB hub with 4 drives, connected to the motherboard port) introduce too much latency?

Alexey Tarasov: Successfully tested

2007-08-19T05:29:06+00:00

Since last post were added loading of RAM-drive, using httpfs precaching and some other small updates and bugfixes, most of time was spent for testing.

Now rootpath option is used to specify location of root on web server. Also, I’ve found that bootp() doesn’t sets nameip (it was not usually needed for NFS loader, it’s enough to specify IP of server and resolving is not required. But in case of web0servers, which may use virtual servers for different domains for same IP - it’s needed to know domain name, and nameserver option is needed) and thus gives problems for code to work, so by default own DHCP client is used. If not domain name but IP is specified in rootpath, then bootp() may be used.

Loading of RAM-drive is optional, but was needed to test correct working of code. It’s done simply by adding few lines to loader.rc script. Actually, it’s possible use for example NFS after loading as root file system (by setting appropriate environment variables), but as long as pxe_http library code must be a little bit independent – best choice was to use RAM-drive (or additionaly to write kernel module for support httpfs. Last variant needed more time and knowledge, so it temporarily was thrown away).

RAM drive image was got from boot floppy image (mfsroot.gz). It contains needed for system installation files. So, after loading by pxe_http kernel+RAM drive it’s possible to install FreeBSD by choosing ftp as media source.

While testing code in LAN I’ve found that loader trys to get file by small portions (maximum 4096 bytes per request). It is not very optimal, so about month ago I was thinking about simple caching mechanism and now it works. For this purpose, httpfs need access to socket receive buffer (this is done to reduce memory usage, so cached information is actually stored in socket buffer, main problem is in removing from buffer header and watching when cached data is empty). Such ability breaks abstraction of code layers, but raises up connection speed and reduces load of http server. While testing it lowered downloading time from about one minute to 25-30 seconds. After setting lower waiting time in pxe_await.h, code response to incoming packets become higher, and downloading is performed in 15-25 seconds at LAN.

After caching was checked, I’ve started testing of code with remote server, that is really remote and situated in 12 hops from my home computer. Here was first surprise, TCP code was working really strange: some packets were never received. During debugging also bug with resending was fixed (segments were waiting to be acked bigger aequential number, then needed).

So, packets were not receiving and code not worked in WAN. I’ve spent many hours trying to make it work. Ed (my mentor) said simple idea – to tcpdump on server side. Well, I don’t know why this idea have not appeared in my mind itself. tcpdump showed, that all is ok – packets from me correctly are coming to server, and from server to me are also sent, however not acked. Debugging of pxe_core showed that they are not reaching my NIC. I’ve started comparing two dumps and found rather interesting thing: only packets with segment size fuly filled to 1460 (default TCP MSS in pxe_http) were not transmitted correctly. I’ve changed MSS to 1260 (10 hops * 20 bytes is about 200 bytes…) and code started working correctly. Packets were sent with Don’t fragment IP flag, so I think somewhere on the path to me router dropped them cause couldn’t sent it not fragmented. May be it’s just my ISP side problem.

After getting code working correctly in Internet, I’ve tested it on two different web servers (first uses Apache, second one – nginx), both worked correctly. And to make sure code is really working, I’ve managed my friend to try it from his home through ADSL modem (at my home, Internet is got through VPN via ISP Ethernet based network, so router at my home is second computer with pppoe client). It also worked.

Last check was to test again NFS loader after some changes in pxe_open() function. It also worked, so finally code seems ready to be tested widely and tarball of current version of code will be sent as result of GSoC.

Finally, I’ve wrote simple documentation, that may be useful for setting pxe_http to work or use it API. Well, it’s not covers every function of pxe_http code, but gives main information, needed to work with it.

Next two weeks I’m planning get more information about ipv6, spend summer time and do nothing usefull at all, except fixing any simple bugs found in code. Later I’ll try to add ipv6 support for pxe_http and may be implement some other ideas.

Ulf Lilleengen: Huntin’ them bugs

2007-08-17T11:54:56+00:00

More status updates… I’ve been fixing many small gvinum bugs the last couple of weeks:

The state of gvinum objects were changed after reloading. This meant that objects got the wrong state when gvinum was brought up.

Made gvinum always use the most recent configuration it finds when setting object states.

Make sure the newest drive is always the newest, and not the first in the drivelist, as was previously assumed.

Add “growable”-state to be used when a plex is ready to be grown.

Allow a plex to be rebuilt even though it’s also growable.

Do not change the size of the volume until the plex is completely grown.

Add status of growing and rebuild of a plex in the list output.

Prevent rebuild to take over the I/O system increasing access-count at the start and end of the rebuild.

Probably a couple of other fixes as well. Also, I’ve updated the vinum-examples page in the handbook to reflect new features and more practical examples. I’ve posted a “call for testers” on current@, arch@ and geom@, and have received some response from people who are willing to help me test. Thanks to them. I’ve uploaded the code-sample that I’ll be delivering to google here: http://folk.ntnu.no/lulf/gvinum_soc2007.tar.gz

Ivan Voras: GEOM_VIRSTOR debugged

2007-08-14T17:24:28+00:00

I’m pleased to announce another release candidate for GEOM_VIRSTOR, A FreeBSD kernel GEOM class providing storage virtualisation facility, regardless of type of underlying devices or its usage. It is a kind of “virtual memory” for disks – you pre-allocate address space (i.e. make a large virtual drive) and worry later about where to find physical space to back it.

This is a bug fix release – a bug that can cause data corruption on large-ish virtual drives (1 TB+) was fixed.

The development snapshot can be found here – everyone (or, to be precise, everyone with 7-CURRENT) is invited to test it.

Ulf Lilleengen: Cleaning up

2007-08-06T15:40:16+00:00

The last couple of weeks I’ve tested and done bugfixing and cleanup of gvinum code. I refactored some parts to make the code belong where it seems logical. I also implemented growing for striped plexes, but that was quite easy since I could reuse most of the code for growing RAID-5 plexes. Unfortunately I was sick for a week and unable to work.

What remains now is to do more testing (can’t get enough), and write and update documenatation on gvinum. I have updated patches for gvinum at http://folk.ntnu.no/lulf/patches/freebsd/gvinum for both RELENG_6 and CURRENT. I appreciate reports from brave users who tries it out, even if it works

Also, I created a new perforce-branch called gvinum_cache. I’ve currently implemented a read/write-cache to check if this would give much speed-up for gvinum. It’s not very nice for reliability, but could be an option for those who want better performance. Anyway, I’ll update more on this later.

Roman Divacky: Epoll and linuxulator bugs fixing

2007-08-02T16:44:38+00:00

I have implemented epoll() subsystem in the Linuxulator based on kqueue. This was quite simple and the resulting code is about 200 lines of code. Mark Heily sent me his inotify implementation library which works in userland. I looked at the code and its a little buggy so porting to FreeBSD will take a little time. Now I am working on fixing various Linuxulator bugs in preparation for switching 2.6 emulation on default after 7.0R is released. Today I fixed java and my next target is flash9.

Please read emulation@ mailing list and help me with testing.

Alexey Tarasov: Boot-reboot..

2007-08-01T11:40:59+00:00

Finally I’ve booted kernel on real machine without unexpected rebooting it in process of booting.

While testing code, I’ve tried smaller buffers (16, 8, 4, and 2Kbytes were used) and tests figured out, that code with 4 and 2 kbytes is able to boot kernel on real machine, bigger buffers are working on virtual machines. Keeping in mind fact that memory allocation/freeing is done most probably correctly (it’s done by libstand functions, that are trusted) it was difficult to understand why smaller usage of memory for buffers gave such strange results.

First investigation showed, that loader’s heap is allocated over PXE data (in base memory higher 8d000h). That was fixed (higher bound of heap was limited to address from which PXE data starts), but hadn’t solved the problem. Yeah, sad moment, I had faith that problem is in heap allocation. Next suggestion was that pxeboot is rather big binary. In fact, PXE specs recommend to make download of boot images in two steps: remote.0 and remote.1. Remote.0 placed at well-known 7c00h:0000 and must not exceed 32Kbytes (cause “32K size limit provides the advantage of being able to clean up and fail gracefully” (c) PXE Specification). remote.0 determines if system is has adequate resources and downloads remote.1 (in specs to in extended memory at e98000h). Monolithic pxeboot is about 200K, with pxe_http above 240Kb. I don’t know if 32K size is strict requirement or not, pxelinux for example is about 12Kb.

Well, “NFS loader works” I’ve thought and then reduced binary size by removing all pxe_http testing code and code related to support filesystems such as dos. It gave me nearely same size as usual for pxeboot. So, now http loaded kernel boots on my home machine.

While working with DHCP client, I’ve found that I’m doing same work, that was performed in bootp() call in libstand. I was not giving much attention to it, cause my code was working, but after binary reducing thought, that it’s good idea to use already available function. This function mainly depends on udpread/udpsend functions, that were earlier situated in libi386/pxe.c but commented by me while rewriting it’s code a little bit (commented cause it was using pxe_call and etc, that was removed by me form this file).

It was not big deal to rewrite udpread/udpwrite to use pxe_http functions to read/send data, but for this purpose was done “default socket” mechanism for UDP. It’s done with aim not use sockets while calling udpread/udpsend, cause code, which uses them, don’t know about pxe_http sockets. To be more accurate, sending of udp packets doesn’t require socket, it’s enough to call pxe_udp_send(), but incoming packets are coming through filters mechanism and are delivered to appropriate socket buffer. Previously, all data that was filtered out – was going to trash bin, now it goes to “default socket”. and it’s possible to read from it as usual, using pxe_udp_read() function.

So, bootp() began working good (except moment with updating of gateway/nameserver information, that I’ll fix in next few days). The main problem with it was, that bootp() may work only after opening of device, cause after that NIC MAC is known by code, that generates BOOTP packet. Normally, pxe_dhcp_query() – which is now may be wrapper for bootp() – is started from pxe_core_init(), and already knows own MAC. Well, I’ve returned pxe_dhcp_query() to pxe_open() in case if not own DHCP client used (here was bootp() originally). And all began work correctly.

NFS code also uses udpread/udpsend functions, so it was rather logical to try NFS loader. It also works. It’s started working without any doubts. so it’ uninteresting to tell anything about it.

This made me possible to make conclusion that compatibility with old working PXE related code in libi386 is big enough.

So, formally main goal of project is achieved. But there is more work to do:

1. load image of RAM drive and mount root to it, so booting process via http will be fully performed. Now it stopson stage of mounting of root file system.

2. Understand where is problem with memory when I’ve used bigger buffers with big pxeboot binary. It’s rather interesting moment, cause I’ve no idea what might cause rebooting of prefectly loaded kernel in case of bigger buffer size for sockets earlier.

3. Test all and update some code details (well, one of them is that root path is not used by http loader now).

4. write finally whole documentation related to project. I’ve started to write it few times, but it wasn’t finished yet.

5. choose notebook to buy.

These are my tasks for next weeks.

Alexey Tarasov: Kernel loaded

2007-07-25T13:55:04+00:00

httpfs now works. It uses pxe_http code to open keep-alive connections to http-server. Also it ressurects it to life if connection is dead due server’s settings (e.g. timeout or exceeded max requests per connection). Need to think how to make requests optimal. Loader uses 4K buffers at request, may be I’ll add some sort of caching mechanism for httpfs to reduce count of requests to server.

So, it’s possible to use common commands of BTX such as ‘more’, ‘load’, ‘help’. I’ve played a lot with them while testing of http code, rather boring process. But after that one problem with interrupt handling in pxe_core was located. It seems, that end of interrupt is handled not correctly, so interrupt not occurs from time to time till some unrelated top pxe_core code finishes interrupt correctly. Problem is temporarily fixed by ignoring of pxe_isr_occured flag and checking of available incoming frames in pxe_core_recv_packets() despite of value of this flag. Meanwhile TCP code was simplified by rewrtting it in pxe_tcp module, reducing code lines and function count. Testing showed it works identically to previous code, except one silly misprint, that was fixed in new variant of code.

Anyway, it’s possible to load modules, kernel and etc. It’s interesting that loader tries to load gzipped variants of files first, so it performs four requests to server. E.g. we need “loader.rc”, theese files will be requested: “loader.rc.gz.split”, “loader.rc.gz”, “loader.rc.split”, “loader.rc”. It was unexpected and exceeded limits of filters and connections tables, cause connections felt to TIME_WAIT state (keep-alived connection were actively closed by client. Need to try in nearest future sending of “Connection: close” field in header to make passive connection closing at closing of file), no new connections were possible to establish. Well, I’ve added opportunity to free connections structures in this state for establishing of new connections. It’s violates RFC, but helps keep relatively small amount of structures. If PXE_MAX_CONNECTIONS is set to big enough number, then TCP code behaviour is as expected in RFC.

After changing loader.rc to something very simple, my home made kernel was loaded and ‘lsmod’ showed a number of modules. But ‘boot’ command failed (hang or panic depending on which virtual machine and real machine were used). It was frustrating – result is practically visible, but yet goal not achieved. I’ve tried loading of RAM-drives, but also failed.

In bad mood of me normal loader.rc was started. The first surprise is that on VMWare machine I’m see normal booting process till time of mounting of root file system (which is unknown, cause not set by environment parameters in loader and /etc/fstab is empty in Apache’s DocumentRoot directory). Second surprise that another virtual machine hangs during loading of support.4th (according to Apache logs it’s read not completely, about 70-80%) and my real machine just reboots while reading same file. Rather suspicous
So next days I’ll be solving quest for finding why loading of support.4th, which have no nothing criminal in it, may cause such problems and exploring issue with lost somewhere interrupt.

Alexey Mikhailov: status updates

2007-07-22T00:47:00+00:00

For recent status updates of my project, check:

http://wiki.freebsd.org/DistributedLoggingDaemon

Fredrik Lindberg: Seems mdnsd has overcome its shyness

2007-07-21T22:15:54+00:00

As it does not only talk when talked to, it starts conversations too. More technically, more or less all groundwork is done in mdnsd to allow clients (local applications) to do multicast DNS queries. (more…)

Ulf Lilleengen: Growing up

2007-07-17T18:08:15+00:00

Since last post I haven’t really done that much do gvinum, but a few things.

I added a few automated test-scripts to check if a volume behaves properly

Go through test-plan and make sure that gvinum passes the tests.

I’ve been thinking a lot on how to best implement growing RAID-5 plexes.

I’ve implemented growing of RAID-5 plexes.

Now, the first and second points are quite boring to do, but I had to do it. Now the last points were trickier, since I didn’t really know where I should start. Finally I decided the best way was to let the plex overwrite itself! A more detalied explanation can be found in the TODO of my perforce branch. I need to test the implementation a bit now. Other than that, I’ve been a bit lazy on my own work this week, and tried to help other students with reviews etc.

Fredrik Lindberg: Look who’s talking

2007-07-16T10:36:32+00:00

Yep, mdnsd speaks now, actually it has been able to do that for a couple of weeks but I just got probing and announcing working as I wanted it to. (more…)