Zbr's days.
←January→
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    
←2008→
Months
JanFeb Mar
Apr May Jun
Jul Aug Sep
Oct Nov Dec

About TODO Blog RSS Old blog Projects Gallery Notes

Fri, 18 Jan 2008

POHMELFS got initial writing support. 

$ ls -l /mnt/tmp/
total 0
$ echo asdasdasdzxczxczxcqeqweqwe > /mnt/tmp/test 
$ sync
$ ls -l /mnt/tmp/
total 0
-rw-r--r-- 1 zbr users 27 Jan 18 22:29 test
$ cat /mnt/tmp/test 
asdasdasdzxczxczxcqeqweqwe
$ mount | grep pohmel
qweqwe on /mnt type pohmel (rw)
The same data in on server, and it was only written there after sync was executed, i.e. exactly in ->writeback() callback and thus via page cache.
I will describe it in details in the next post.

To be completed (simnple!) FS I have to implement inode operations for special files and link support, both are quite simple (and probably can be postponed), the most interesting idea I have to think about is metadata caching (so far it is write-through cache, which is not optimal, I want write-back one).

Next complex task is cache coherency algorithms. It will be started after testing (including performance) of the initial POHMELFS implementation withouth cache coherency involved at all.

Stay tuned!

/devel/fs :: Link / Comments (0)

Anatomy of the filesystem. Object creation and removal.

Let's first discuss object creation. It is pretty simple, each directory inode has inode_operations structure, which contains ->create()/->mkdir() callbacks. Prototype of both looks like this:

static int pohmelfs_create(struct inode *dir, struct dentry *dentry, int mode,
		struct nameidata *nd);
static int pohmelfs_mkdir(struct inode *dir, struct dentry *dentry, int mode);
Where dir is parent directory inode, dentry is directory entry structure, which contains inode for given object (dentry->d_inode, it is NULL for the object being created, since there is no inode yet for the given dentry), its name (dentry->d_name) and lots of other interesting fields, which are not that interesting for filesystem creation. FS code should allocate space for the new entry and add it there.
At the end one has to fill dentry with new inode info, it can be done either by d_add(dentry, &npi->vfs_inode);, or more correct by d_instantiate(dentry, &npi->vfs_inode);, which is called from d_add(), which then adds dentry into hash chains. Ext2 also multiple times marks inode as dirty, the same does minix. This operation has no effect on network filesystem, afaics, but for block based filesystems it adds inode into dirty list. However, practice shows that d_instantiate(dentry, &npi->vfs_inode); is not enough, and d_add(dentry, &npi->vfs_inode); should be called for network filesystem.

Object removal is essentially the same. There are following callbacks invoked by VFS layer, when object is being deleted: ->unlink() and ->rmdir().
The former is called for usual files, nodes and so on, the latter - when you call rmdir(). Both have following prototype:
static int pohmelfs_unlink(struct inode *dir, struct dentry *dentry);
static int pohmelfs_rmdir(struct inode *dir, struct dentry *dentry);
Where dir is parent directory inode and dentry contains directory entry, which in turn has inode pointer and name of the object.
Filesystem should remove appropriate object from the disk, update its fields and mainly offsets, used in the ->readdir() callbacks.

All described callbacks should return negative error value or zero in case of correct completion.

/devel/fs :: Link / Comments (0)

Fedora upgrade sucks.

Since I got fast internet connection I decided to upgrade Fedora Core 7, installed on my laptop to its next version via yum. Machine has 256 Mb of RAM and 512 Mb of swap, so I expeted there should not be problems, but I was wrong - it ended up with OOM condition and yum got stuck, so I killed it (with SIGKILL signal, since it did not respond to anything else). Subsequent runs end up with trnsaction check error where some packets (likely just installed) conflict with other ones (probably with old versions), and I expect, that machine will be unusable after susped/resume or reboot, and there is no way to rollback installed packets...
Although I started downgrade process, it is about 3 o'clock in Moscow, so I will move to bed and hopefully things will be resolved this morning.

Another serious design problem of the whole yum system is its dependency tracking system. It requires to download 3-5 Mb sqlite database almost every time one wants to install any single packet, which can even do not have any dependencies to be resolved, or when its size is about several kilobytes.

/devel/other :: Link / Comments (0)