Filesystems handling

[Jeko]

I've written my Virtual File System, that is code to handle filesystems in an abstract way.

There are some functions that a generic filesystem must implement, for example Lookup, Mkdir, Mknode, Readdir, etc.

There are also functions to modify node's values, for example Chmod, Chown...

Now I think that maybe I can use an only function, Dirty, that will write the new informations on the inode, only when the inode will be freed from the Virtual File System (an inode is freed only when no one is using it), so I can have all the inode modifications only in memory saving drive accesses.

What do you think? Is it better to have separate functions or an unique function to call only when an inode must be freed?

[jal]

so I can have all the inode modifications only in memory saving drive accesses.

Which is a disaster when you have a power failure, or a kernel crash.


JAL

[Jeko]

so I can have all the inode modifications only in memory saving drive accesses.

Which is a disaster when you have a power failure, or a kernel crash.


JAL

Yes, you're right, it's a disaster in these events...
But also for the block cache these things can happen... So mustn't you use any block cache? But without a block cache the system will be very slow... Then?

[Combuster]

Assuming write-through caching, which means that once you write something, it is put into the cache and appended to the disk's write queue.

It's still fast because:
1) You can still read back written data from the cache without going to disk.
2) Data that is read multiple times only needs to be fetched from disk the first time.
3) And, if you overwrite something, you might save a disk access when the written sector hasn't been committed yet

It's about as safe, because:
If a crash would happen, then the same amount of data would be actually written to disk as without the cache, so you'd lose the same amount of data at worst (and probably less because read accesses are reduced as well).

The only problem is with programs that require a certain disk write order, they'd need a way to force a synchronization of a subset of data to the disk (or alternatively, use strong write ordering which however goes at the cost of optimization #3)

[TheDragon]

Might I also add that before you get to far into your project, (call me a .NET programmer(for I am) ) rename your VFS functions to PascalCasingWithDescriptiveNames. The theory, and in my case, at least, practice, is that it saves you a lot of time because you don't have to look up what cryptic terse name you named it. Trust me.

[Jeko]

Might I also add that before you get to far into your project, (call me a .NET programmer(for I am) ) rename your VFS functions to PascalCasingWithDescriptiveNames. The theory, and in my case, at least, practice, is that it saves you a lot of time because you don't have to look up what cryptic terse name you named it. Trust me.

Yes, infact for my Virtual File System I use VfsLookup, VfsMkdir, VfsRequest, et cetera.

[ru2aqare]

Yes, infact for my Virtual File System I use VfsLookup, VfsMkdir, VfsRequest, et cetera.

I don't think TheDragon was referring to that (the so-called and infamous Hungarian notation) - I think he was referring to more descriptive names like CreateDirectory, LookupFile (or LookupDirectory or LookupWhatever), RequestBlock, and so on. Mkdir should be obvious to everyone, but VfsLookup may not be...

[Jeko]

Yes, infact for my Virtual File System I use VfsLookup, VfsMkdir, VfsRequest, et cetera.

I don't think TheDragon was referring to that (the so-called and infamous Hungarian notation) - I think he was referring to more descriptive names like CreateDirectory, LookupFile (or LookupDirectory or LookupWhatever), RequestBlock, and so on. Mkdir should be obvious to everyone, but VfsLookup may not be...

Yes... But:
VfsMkdir is, as you written, obvious.
VfsLookup is the function that lookups all types of nodes (files, directories, devices, et cetera). It's an only function for each lookup, so only VfsLookup
VfsRequest is a function that does a request on a node, but this isn't a request of a block. The request can be READ, WRITE or IOCTL, or also a user-defined request (so it's extensible by programmers). So it is a general request, and, like the general lookup, is called only VfsRequest.

[JackScott]

VfsRequest is a function that does a request on a node, but this isn't a request of a block. The request can be READ, WRITE or IOCTL, or also a user-defined request (so it's extensible by programmers). So it is a general request, and, like the general lookup, is called only VfsRequest.

You've just had to explain what a function does to us: that was the point being made.

[Jeko]

VfsRequest is a function that does a request on a node, but this isn't a request of a block. The request can be READ, WRITE or IOCTL, or also a user-defined request (so it's extensible by programmers). So it is a general request, and, like the general lookup, is called only VfsRequest.

You've just had to explain what a function does to us: that was the point being made.

Which can be a better name to VfsRequest?

[ru2aqare]

Which can be a better name to VfsRequest?

I would separate the read, write and generic control functions, and instead of a generic VfsRequest function I would have three functions that perform specific tasks: VfsRead, VfsWrite, VfwControl.

Actually, the driver model of my kernel separates a device request into four (or five) types: read, write, get information, set information, and other (currently unspecified, reserved for future expansion) IOCTL requests, but that may be too much.