* [Lustre-devel] max_dirty_mb and fsync @ 2009-10-15 18:52 Bradley W. Settlemyer 2009-10-16 15:37 ` Bradley W. Settlemyer 2009-10-17 17:53 ` Andreas Dilger 0 siblings, 2 replies; 3+ messages in thread From: Bradley W. Settlemyer @ 2009-10-15 18:52 UTC (permalink / raw) To: lustre-devel Hello What is the difference between setting the max_dirty_mb setting in /proc to 4 and making sure that all of my applications fsync every 4MBs of data that are transmitted? I would guess that one difference is the 32MB is a filesystem-wide setting rather than a per file setting -- so the sync occurs regardless of the number of files receiving data. But are there any other differences with regards to the interaction with the file system. More to the point perhaps, does an fsync have additional side effects beyond those that occur for the max_dirty_mb threshhold being exceeded? Cheers, Brad ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Lustre-devel] max_dirty_mb and fsync 2009-10-15 18:52 [Lustre-devel] max_dirty_mb and fsync Bradley W. Settlemyer @ 2009-10-16 15:37 ` Bradley W. Settlemyer 2009-10-17 17:53 ` Andreas Dilger 1 sibling, 0 replies; 3+ messages in thread From: Bradley W. Settlemyer @ 2009-10-16 15:37 UTC (permalink / raw) To: lustre-devel Obviously, when I write 32MB in the second paragraph I mean 4MB. Sorry for the error. Cheers Brad On 10/15/2009 02:52 PM, Bradley W. Settlemyer wrote: > Hello > > What is the difference between setting the max_dirty_mb setting in > /proc to 4 and making sure that all of my applications fsync every 4MBs > of data that are transmitted? > > I would guess that one difference is the 32MB is a filesystem-wide > setting rather than a per file setting -- so the sync occurs regardless > of the number of files receiving data. But are there any other > differences with regards to the interaction with the file system. > > More to the point perhaps, does an fsync have additional side effects > beyond those that occur for the max_dirty_mb threshhold being exceeded? > > Cheers, > Brad > > _______________________________________________ > Lustre-devel mailing list > Lustre-devel at lists.lustre.org > http://lists.lustre.org/mailman/listinfo/lustre-devel > ^ permalink raw reply [flat|nested] 3+ messages in thread
* [Lustre-devel] max_dirty_mb and fsync 2009-10-15 18:52 [Lustre-devel] max_dirty_mb and fsync Bradley W. Settlemyer 2009-10-16 15:37 ` Bradley W. Settlemyer @ 2009-10-17 17:53 ` Andreas Dilger 1 sibling, 0 replies; 3+ messages in thread From: Andreas Dilger @ 2009-10-17 17:53 UTC (permalink / raw) To: lustre-devel On 15-Oct-09, at 12:52, Bradley W. Settlemyer wrote: > What is the difference between setting the max_dirty_mb setting in > /proc to 4 and making sure that all of my applications fsync every > 4MBs > of data that are transmitted? > > I would guess that one difference is the 32MB is a filesystem-wide > setting rather than a per file setting -- so the sync occurs > regardless > of the number of files receiving data. But are there any other > differences with regards to the interaction with the file system. > > More to the point perhaps, does an fsync have additional side effects > beyond those that occur for the max_dirty_mb threshhold being > exceeded? One important distinction between max_dirty_mb (which is a Lustre mechanism to avoid too much file cache memory pressure on the client node causing application data to be paged out of memory) and an fsync() is max_dirty_mb only pushes out file data to the OSTs on an as-needed basis, while fsync() flushes ALL of the data, and also guarantees that you can ACCESS that data after it was written to the OSTs/disks. Whether on Lustre or a local filesystem, just because the blocks are on disk, it doesn't mean that the metadata (either Lustre on the MDS, or ext3/ xfs/etc) to access that data (whether for the pathname traversal, or the inode itself) is also safe on disk. This is one of the issues being discussed a lot on linux-fsdevel regarding the semantics of O_DIRECT, which guarantees that the DATA is on disk but it doesn't mean that the just-created inode or the mapping for just-allocated blocks have made it to the disk at all. That behaviour is fine for a database, which will generally always preallocate the file on disk, so the only thing changing is the file data, but it may be a surprise to other users of O_DIRECT. That said, Lustre WILL of course write all of this data to disk as soon as practical, without forcing everything to a standstill while the fsync() is completed. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-10-17 17:53 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-10-15 18:52 [Lustre-devel] max_dirty_mb and fsync Bradley W. Settlemyer 2009-10-16 15:37 ` Bradley W. Settlemyer 2009-10-17 17:53 ` Andreas Dilger
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.