Technically, yes, it can fragment if there is not much free space available, and no, it doesn't clean up after itself. To check the fragmentation level of a partition:
fsck -nvf /dev/sda1 # replace sda1 with the relevant partition
and to see how fragmented a particular file is:
filefrag -v /path/to/file
Here is an article about how to defrag a Linux system, but chances are it is not affecting your system to a noticeable degree, so you don't need to worry about it.
If you're really interested, this article and its follow up were extremely helpful to me in understanding how the file system works.
when is data in the journal transferred to the disk?
Depends on two main things: the file system in use and the physical storage
device. XFS uses write barriers. EXT3 uses write
barriers, if enabled. EXT4 has barriers on by default. Traditional HDDs use caches. Solid-State Drives may or may not have a cache. Ultimately, it is a combination
of the operating system, file system and underlying hardware architecture and
specifications that determine when data is persisted on the storage device.
is the write complete to the user when the data is written to the journal or
to the disk?
This also depends on the application in use and your operating system. Linux
has the fsync system call that applications and file systems use to
flush cached data to the physical devices. Not all applications use fsync to
explicitly flush cached data to storage. You can always issue a sync
command to manually flush file system buffers.
How is disk defragmentation related to journal?
Disk fragmentation affects performance, especially when dealing
with large files whose blocks are not contiguous. There are different
techniques for mitigating fragmentation. For example, XFS and
other file systems use an allocate-on-flush technique to minimize
fragmentation.
Best Answer
On ext3 and ext4 filesystems it's stored either in the journal inode (the default) or on a separate device, depending on the options passed to
mke2fs.