Re: atomicity

Helge Hafting (helge.hafting@daldata.no)
Mon, 07 Dec 1998 09:47:07 +0100

> Is there a way for a program to make a section of code atomic? I think
> it would be useful to allow root programs (or, for added security, root
> programs with special permissions or listed in a certain file) to
> protect a certain section of their code so thoroughly that while in that
> section
> a) the scheduler will not interrupt them
That would give us very bad performance, and surely lots
of people who don't know better would abuse such an interface. :-(
> b) they cannot receive _any_ signals, including SIGKILL
>
> If this feature does not exist, I am guessing that writing it will make
> it more possible to write such things as background defragmenters,
> though additional kernel interfaces would probably be needed to keep the
> FS from confusing itself..... e.g.
Dealing with the disk drive takes a looooong time. And nothing
else should happen at the same time? We shouldn't be able
to use the idle cpu for anything else while the
defragmenter wait for a disk read?

> defragmenter enters protected block
> defragger moves a disk block
What if this block contains the code for the defragger itself, and the
defragger gets a page fault requiring this block? You can't prevent
the swap code from needing the disk with a scheduler block.

> defragger modifies inode to reflect change
> defragger tells FS about change
I believe telling the FS about the change would be hard - I don't
think the many different filesystems are written with that in mind.

> defragger exits protected block
>
> (note: some changes would be needed for safety: maybe tell FS about
> change, then implement, then tell FS complete..., have various dirtiness
> flags......)
>
> So the defragmenter flipped around parts of the disk without anybody
> else caring. With the defragger running as an idle-process only when
> the system load is low, it can effectively keep the disk at near-zero
> fragmentation without serious slow-down.

There is normally little need for this as ext2 try to avoid fragmentation
in the first place. It will typically not fragment if you don't
fill the disk completely.

But if you need a defragger - here is the way to do it without messing
with the kernel:

1. umount the filesystem you want to defragment
2. Run a defragger against that partition
3. Re-mount the now defragmented filesystem.

The root user is permitted to mount/umount any filesystem, and do
also have write access to any unmounted partitions.

Defragmenting a big filessytem may need some time, so if you want to
do this in the background, change the defrag program so it exits
after a few seconds. You can then have a defragment daemon that runs
the umount/defrag/mount calls now and then when the load is low.

This technique will probably not work for stuff like /usr that
need to be mounted all the time for normal operation, but you probably
don't need to defrag /usr anyway. A well planned partition layout
is a good idea if performance is what you want anyway.

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/