Hi Group,

I am running Slackware 12.2 as a Samba server.
I have backups on a separate disc, but want to confirm whether these ext3 tuning options may cause data loss and cause the need for a complete reinstall.

Here's my current disc arrangement as shown in /etc/fstab:

/dev/sda1 swap swap defaults 0 0
/dev/sda2 / ext3 defaults 1 1

I want to do the following to the ext3 partition:

/dev/sda2 / ext3 defaults,noatime,data=writeback 1 1

- - - - - - - - - -

I will run the following command to accomplish the data=writeback:

tune2fs -o journal_data_writeback /dev/sda2

- - - - - - - - - - -

Is this safe to do?
Might it cause data loss?
I don't see anything in the tune2fs manpage indicating data loss under any circumstance.

Do I have to provide any parameters or instructions in /etc/lilo.conf:

append=" vt.default_utf8=0"
boot = /dev/sda
lba32
image = /boot/vmlinuz
root = /dev/sda2
label = Linux
read-only


Thanks for your time and patience.

It is known to be safe and works as expected.

The kernel definitely supports it(?)

Thank you for your response, Amani.
I will check all ext3 module support in the kernel.

Wrt data loss IMHO the best way to handle changing write_order is to run the commands from a Live CD and /forcefsck on reboot.

But if you're changing write_order for speedups and your machine doesn't suffer from blackouts and the data isn't crucial, why not ditch journalling completely and mount as ext2 + noatime + nodiratime or use a faster filesystem?

unSpawn thanks for your reply, much appreciated.
I thought ext3 actually had some caching capabilities that make it faster than ext2 in many instances, and ext3 uses space on disc more efficiently in choosing/populating blocks with data.

You have me interested about maybe using an altogether different filesystem for highest performance capabilities. What do you suggest I look into?
All pointers to RTFM here and there are greatly appreciated.

Thanks for your time.

EXT3 has some over head because of its journal. This journal can be placed on another hard drive for better performance. The next file system that you should try assuming the computer has at least 512 MB of RAM or more is XFS. XFS can be very fast, but only if you specify format options to make it perform well. JFS is another file system, but it has the same flaws as FAT. JFS gets fragmented and there is no utilities to defrag it. XFS has a built in defrag feature that it does over time just like EXT2/3. XFS has an option in one of its utilities. This option forces the defrag feature of XFS which is a cheap way for defragging. This cheap way of defragging has no brains of organizing data for certain task of the system. XFS makes a good reliable and fast alternative to EXT3. Since XFS is journal file system, the over head is still there.

Excellent post by Electro. I'll just dump some links to peruse:
http://fsbench.netnation.com/ (?)
http://linuxgazette.net/102/piszcz.html (2004)
http://www.debian-administration.org/articles/388 (2006)
http://www.linuxquestions.org/questi...r-ext3-406978/ (2006)
http://www.linuxquestions.org/questi...server-689906/ (2008, note linkage inpost #3)
http://linux.com/news/software/linux...enchmarks-pt-2 (2009)

According to the latest set of benchmarks from this 2009 article linked by unSpawn, ext3 compares very successfully against other filesystems.

http://linux.com/news/software/linux...enchmarks-pt-2

Wanted to report back so this thread may confirm for others in the future.

I started with this ext3 setup in /etc/fstab:

/dev/sda2 / ext3 defaults 1 1

I changed /etc/fstab to:

/dev/sda2 / ext3 defaults,noatime,data=writeback 1 1

And then executed command on root partition:

tune2fs -o journal_data_writeback /dev/sda2


Works.
No data loss.
No problems.