* [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.