I'm using XFS on top of some EVMS volumes.
I'm getting the same barriers not supported message when mounting, but otherwise everything works allright.
I'm a little bit curious about the in-kernel device-mapper implementation and how it doesn't know to implement write barriers on top of the real hardware. Perhaps someone with more knowledge could provide more information on this...?

What could be the possible consequence of not having write barriers enabled? Anyone?

I have to say there is very little information to find about JFS. So I decided to find it out myself. I'm testing a combination of JFS / XFS now. The overall feeling is quite good, but that's also the case whenever I start using a newly formatted ext3 filesystem. So lets see what happens when time goes by._________________Alle dingen moeten onzin zijn.

What could be the possible consequence of not having write barriers enabled? Anyone?

I have to say there is very little information to find about JFS. So I decided to find it out myself. I'm testing a combination of JFS / XFS now. The overall feeling is quite good, but that's also the case whenever I start using a newly formatted ext3 filesystem. So lets see what happens when time goes by.

Some situations will keep the log data in cache instead of getting written to disk first. If your system crashes or has power loss your disk could lose serious data or metadata to the point of not being recoverable.

I have Pentium II (Deschutes) with first 10GB (/dev/hda) and second 60GB(/dev/hdc) disk.
After reading this thread and some SGI docs and FAQs I came with this options for creating FS and mounting the disks:

1) To create XFS on hda:

Code:

# mkfs.xfs -l internal,size=128m -d agcount=2 /dev/hda

I've also seen "d unwritten=0" option:
mkfs  Unwritten Extents
 Unwritten extents are used to support pre-allocation.
 Default is enabled.
 To disable unwritten extents you would use:
# mkfs d unwritten=0 device
Filesystem write performance may be negatively affected for unwritten file extents,
since extra filesystem transactions are required to convert extent flags for the
range of the file written.

So my question:
Is it safe to add d unwritten=0 option to increase performance like this (or will I lose some essential functionality)?:

Code:

# mkfs.xfs -l internal,size=128m -d agcount=2 d unwritten=0 /dev/hda

2) To prevent data lost in case of power outage(Disabling the write back cache):
Add the following to local.start:

On this thread it's suggested that the mount options should be "noatime,logbufs=8"

But what about "osyncisdsync" mount option.

 osyncisdsync
 Writes to files opened with the O_SYNC flag set will behave as if the O_DSYNC flag
had been used instead.
 This can result in better performance without compromising data safety.
 However timestamp updates from O_SYNC writes can be lost if the system crashes.
Use osyncisosync to disable this setting.

So do you think it is safe to add "osyncisdsync" mount option to fstab?

I've also seen "d unwritten=0" option:
mkfs  Unwritten Extents
 Unwritten extents are used to support pre-allocation.
 Default is enabled.
 To disable unwritten extents you would use:
# mkfs d unwritten=0 device
Filesystem write performance may be negatively affected for unwritten file extents,
since extra filesystem transactions are required to convert extent flags for the
range of the file written.

So my question: Is it safe to add d unwritten=0 option to increase performance like this (or will I lose some essential functionality)?:

I think that performance gains with unwritten extents are negligible, so I would rather pass that option out. Write performance is affected, because FS needs to convert extents from unwritten to written throughout the site of file that is being written. If someone could make a few tests, that would be nice, but I think it's not some magic option.

biggyL wrote:

2) To prevent data lost in case of power outage(Disabling the write back cache):
Add the following to local.start:

Disabling writeback cache also significantly reduces performance, but then again, test it first, maybe it's not such a big deal.

biggyL wrote:

3) Mount options:

On this thread it's suggested that the mount options should be "noatime,logbufs=8"
But what about "osyncisdsync" mount option.

 osyncisdsync
 Writes to files opened with the O_SYNC flag set will behave as if the O_DSYNC flag
had been used instead.
 This can result in better performance without compromising data safety.
 However timestamp updates from O_SYNC writes can be lost if the system crashes.
Use osyncisosync to disable this setting.

So do you think it is safe to add "osyncisdsync" mount option to fstab?

I haven't tested this option either... Could someone run Bonnie and post results?_________________I avenge with darkness, the blood is the life
The Order of the Dragon, I feed on humanlife

On this thread it's suggested that the mount options should be "noatime,logbufs=8"
But what about "osyncisdsync" mount option.

 osyncisdsync
 Writes to files opened with the O_SYNC flag set will behave as if the O_DSYNC flag
had been used instead.
 This can result in better performance without compromising data safety.
 However timestamp updates from O_SYNC writes can be lost if the system crashes.
Use osyncisosync to disable this setting.

So do you think it is safe to add "osyncisdsync" mount option to fstab?

I haven't tested this option either... Could someone run Bonnie and post results?

There is no need to add "osyncisdsync" to fstab, because it is enabled by default since 2002..._________________Myself and mine gymnastic ever

Here is a response from Timothy Shimmin from SGI (at least his e-mail addr. have @sgi.com ) on my "unwritten=0" query:

My understanding (although I'm not familiar with that code), is that unwritten extents are used in space preallocation.
So unless you reserve space for a file it will not have an effect.
And if you do, then setting "unwritten=0" will speed up writes because it doesn't need to flag the unwritten extents and write out the extra transactions for this.
If the unwritten extents aren't flagged as such then there can be a security issue where one can read old data (other's data) for these unwritten parts.
In fact, the security issue on preallocation (1997-98 sgi-pv#705217) was what motivated the idea of flagging extents as unwritten in the first place.
----------

So my choice is to set "unwritten=0" on this particular machine (PII with only one console access user - root )

I am really interested in data journaling in XFS. Is it in there somewhere? I have had quite a few lost files on XFS when power goes down (those files were filled with garbage). Did something change in that matter?

# NOTE: The next line is critical for boot!
proc /proc proc defaults 0 0

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
# use almost no memory if not populated with files)
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0

Last edited by biggyL on Tue May 01, 2007 8:31 am; edited 1 time in total

I'd like to share xfsdump script (I wrote awhile ago) I'm using to route 1 full and 6 incremental backups during the week.
I'm using xfsdump to make dumps and xfsinvutil to prune (manage) sessions on the date of xfsdump.

I think your partition is heavily fragmented. And you cannot defragment it, as there is not enough free space. First move some files to make space and then re-run xfs_fsr. It seems that you need at least 8175333596 bytes, i.e. 7.6 GB insted 7.1 GB actually free, but if you have much more free space, xfs_fsr will be faster.

This became an issue at around kernel 2.6.17 where write barriers became a default option; some kind soul pointed me in this direction (http://lkml.org/lkml/2006/5/19/33), which is a thread on LKML where an XFS developer is discussing the merits/tradeoffs of write barriers and comments on some benchmark results. They (SGI XFS devs) later addressed this in the XFS FAQ, where the official word
from (http://oss.sgi.com/projects/xfs/faq.html) is:

Code:

Write barrier support.

Write barrier support is enabled by default in XFS since 2.6.17. It is disabled by mounting the filesystem with "nobarrier". Barrier support will flush the write back cache at the appropriate times (such as on XFS log writes). This is generally the recommended solution, however, you should check the system logs to ensure it was successful. Barriers will be disabled and reported in the log if any of the 3 scenarios occurs:

If the filesystem is mounted with an external log device then we currently don't support flushing to the data and log devices (this may change in the future). If the driver tells the block layer that the device does not support write cache flushing with the write cache enabled then it will report that the device doesn't support it. And finally we will actually test out a barrier write on the superblock and test its error state afterwards, reporting if it fails.

Q. Should barriers be enabled with storage which has a persistent write cache?

Many hardware RAID have a persistent write cache which preserves it across power failure, interface resets, system crashes, etc. Using write barriers in this instance is not warranted and will in fact lower performance. Therefore, it is recommended to turn off the barrier support and mount the filesystem with "nobarrier".

LOL - glad it helped. I'm laughing because I nearly junked XFS as well back then after upgrading to a >2.6.16 kernel, not realizing that the new feature had been defaulted. FYI - as you can read, it's not recommended to disable the write barrier on a system with no RAID/provisions for recovery but honestly I've run a laptop happily with most of the filesystem under XFS for a long time with little trouble and no recovery issues to speak of despite lockups, kernel oopses, and booting unstable/testing kernels [such as viper-sources ] on that machine.

vipernicus wrote:

a7thson wrote:

Not sure it's quite the answer you're looking for, however.

No, that's great information, I just needed to know if removing it would cause more harm than good.

I mounted the partition with nobarrier, and wow, big difference.

real 0m31.367s

Quote:

Edit:
Although, ext3 w/ -o noatime,commit=60,data=writeback I get:

I run / on ext3 with similar options actually. Mostly I entrust larger files, torrent/p2p downloads, media and raw media, plus distfiles,packages and /home to XFS_________________i7-3610QM | E5-2670 | FX-8300