similar to: application level write ordering guarantees?

If I want to make sure a file has really been deleted do I have to: 1. fsync the file 2. fsync the directory the file is in 3. both? Much thanks. -- Ben Escoto

Hi, I have a doubt in the ordering of writes in ext3. Any help is appreciated. Ext3 enforces certain ordering in writes to ensure data integrity. For example, the journal writes are issued first and only after their successful completion the actual writes are issued. Sometimes we need to maintain ordering across transactions also. This is needed because if the actual writes of one transaction

Hi, I have a question on fsync() and ext3's journaling modes. Assume that I call fsync(fd) on a file. If that file is in 'data=journal' mode, would the fsync() return once the data gets safely into the journal ? On the other hand, if that file is in 'data=writeback' mode, would the fsync() return only when the data gets safely into its actual location ? Any help is

My application always needs to sync file data after writing. I don't want anything handing around in the kernel buffers. I am wondering what is the best method to accomplish this. 1. Do I use EXT2 and use fdatasync() or fsync()? 2. Do I use EXT2 and mount with the "sync" option? 3. Do I use EXT2 and use the O_DIRECT flag on open()? 4. Do I use EXT3 in full journaled mode,

Hello, Many warm thank yous to Bill Rugolsky Jr. and Stephen Tweedie for their help on this one. Both pointed out that since the file system is journaled, if the primary box (nas1) were to crash, the secondary box should mount the ext3 file system without any problems. Depending on the nature of the journal (metadata journaling and/or data journaling), we may have little or no data loss. Bill

Hi all, We are building a new system which is going to use ext3 FS. We would like to know more about the behavior of ext3 in the case of failure. But before I procede, I would like to share more information about our future system. * Our application always does an fsync on files * When symbolic links (more specifically fast symlink) are created, the host directory is also fsync'ed. * Our

I don't think that XFS is a desktop filesystem at all. This is from XFS FAQ: qoute ------------ Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? If it hurts don't do that! * NOTE: XFS 1.1 and kernels => 2.4.18 has the asynchronous delete path which means that you will see a lot less of these problems. If you still have not updated to the 1.1

Hi, I've been wondering exactly what you gain by using journaled mode over ordered mode. Are there any known cases where journaled mode could recover where ordered mode wouldn't? Mike

Hello, We found that fsync and fdatasync syscalls sometimes don't sync data in an ext3 file system under the following conditions. 1. Kernel version is 2.6.6 or later (including 2.6.8.1 and 2.6.9-rc2). 2. Ext3's journalling mode is "data=journal". 3. Create a file (whose size is 1Mbytes) and execute umount/mount. 4. lseek to a random position within the file, write 8192 bytes

On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity <avi@redhat.com> wrote: > On 04/09/2010 05:56 PM, Ben Gamari wrote: > > On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleen<andi@firstfloor.org> wrote: > > > >> Ben Gamari<bgamari.foss@gmail.com> writes: > >> ext4/XFS/JFS/btrfs should be better in this regard > >> > >> >

The latest ext3 patches against linux-2.4.7 and linux-2.4.7-ac3 are at http://www.uow.edu.au/~andrewm/linux/ext3/ Changes since 0.9.4 include: - Fixed a bug which could trip an assertion failure when using small journals under heavy load in full data journalling mode. - A patch from Ted plus the latest version of e2fsprogs plus the stomping of various ext3 bugs gives us preliminary

Greetings. I am Arul Selvan works for Novell. I am exploring the Ext4 architecture, more specifically i would like to understand the write ordering, basically the same blocks is modified more than once, how the write is ordered. Could you point me the doc or the specific source file to look. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Are SQLite users that are worried about losing data that has been committed (fsynced) better off setting data=journal than data=ordered (or even data=writeback)? The context is trying to reduce the number of writes to a flash file-system without sacrificing data integrity in the event of a power failure or OS crash. Thanks, Dan Kennedy.

Postfix <http://www.postfix.org> does a chattr +S on its spool directory when it is installed on Linux. This is what is written in the postfix startup script -- # # LINUX by default does not synchronously update directories - # that's dangerous for mail. # if [ -f /usr/bin/chattr ] then CHATTR="/usr/bin/chattr +S" else CHATTR=echo fi -- Is this still required on ext3 ?

Hi All ; One of our customer is suffered from FS being corrupted after an unattanded shutdonw due to power problem. They want to switch to ZFS. >From what I read on, ZFS will most probably not be corrupted from the same event. But I am not sure how will Oracle be affected from a sudden power outage when placed over ZFS ? Any comments ? PS: I am aware of UPS''s and

I'm running Linux travis 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686 GNU/Linux on a laptop with ext3 on / Some time ago things started getting weird in the following way: I do a fairly normal hack, ^Z, make, test loop when developing and it seems that vim is calling fsync or sync and that is then flushing everything to disk. My tests create maybe 10 dozen files in ~30MB and for some

Hello, Is there some document about ext3 performance tuning and choosing the right type and size of journal? Except RedHat's white paper. From what I read I understood that for typical operations data=ordered is prefered. For the cases when there are many writes not appending to files data=journal is the choice. And if I want to get the most performance or in case where program is doing

thanks that answered my question. One more question, is it possible to stop the delayed block allocation in ext4 ? >>> Andreas Dilger <adilger@dilger.ca> 6/3/2013 8:17 PM >>> On 2013-06-02, at 23:33, "Arul Selvan" <Rarul@novell.com> wrote: > Greetings. I am Arul Selvan works for Novell. I am exploring the Ext4 architecture, more specifically i would like

Greetings all, I have a question regarding the fsync data corruption bug that was introduced in 2.4.20 when using data=journal. I have patched the 2.4.20 kernel with the 3 sync patches available from zip.com.au, and I am wondering if with these patches the "bug" still exists: sync_fs.patch sync_fs-fix.patch sync_fs-fix-2.patch In addition the following two patches have also

Greetings. If I issue the following sequence of pseudo-syscalls: fd = open(temp_file, O_WRONLY) write(fd) rename(temp_file, dest_file) fsync(fd) close(fd) (where dest_file is in a different directory) Does ext3 order the commit such that the file write effectively happens in the journal before the rename? That is, is there any chance that, if a crash occurred, that the destination