>><tt><tt>nothing better than benchmarking your app with different<br><br>IO performance is always a consideration, but for this application reliability is much more important.  <br><br>I am looking for the most reliable way of dumping files to disk.  We I call close(), I need to know that the data is one disk.  It doesn't need to be the highest performance method, just the most reliable.<br><br>>></tt></tt>Unless your filesystem is constantly busy<br><br>It is constantly busy.  Each file system manages around 10 millions files across a TB.  Each day, an average of 500,000 files totaling 100G are throw away while the same amount is generated.  Its a constant cycle.  The point is, these are very active file systems. <br><br>I have already seen EXT3 corrupt its superblock(s) after a disk failure, using data=ordered.  Trying different superblocks didn't work, maybe -O sparse_super isn't the best idea.<br><tt><tt><br>No merit
 in EXT2 with fdatasync calls?<br><br>thanks for the response.<br><br></tt></tt><b><i>Andreas Dilger <adilger@clusterfs.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> On Mar 21, 2007  16:51 -0700, brian stone wrote:<br>> 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.<br><br>>  4. Do I use EXT3 in full journaled mode, where the data and metadata are journaled? In this case, is the journaled data sync'd or async'd? When the journal commits the data to the file system, is that sync'd or dumped into kernel buffers?<br>>  <br>>  5. Since I will always be syncing the data, does it make any sense to use EXT3? It feels like the EXT3 journal would be unnecessary.<br><br>In theory, ext3 + data=journal will give you the best performance,
 because<br>sync IO will always be linear IO to the journal.  Unless your filesystem is<br>constantly busy, then the writes to the filesystem can happen asynchronously<br>after being committed to the journal without danger of being lost.<br><br>That said, nothing better than benchmarking your app with different<br>filesystem options to see which one is best.<br><br>Cheers, Andreas<br>--<br>Andreas Dilger<br>Principal Software Engineer<br>Cluster File Systems, Inc.<br><br></blockquote><br><p>

<hr size=1>Don't be flakey. <a href="http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/mail">Get Yahoo! Mail for Mobile</a> and <br><a href="http://us.rd.yahoo.com/evt=43909/*http://mobile.yahoo.com/mail">always stay connected</a> to friends.