From: "Anton Salikhmetov" <salikhmetov@gmail.com>
To: "Rogier Wolff" <R.E.Wolff@bitwizard.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mtime updates for mmapped files.
Date: Wed, 16 Jan 2008 14:22:49 +0300 [thread overview]
Message-ID: <4df4ef0c0801160322j31645554oa6faec5cca64509d@mail.gmail.com> (raw)
In-Reply-To: <20080116094640.GA2071@bitwizard.nl>
2008/1/16, Rogier Wolff <R.E.Wolff@bitwizard.nl>:
>
> Hi,
>
> I wrote a small app yesterday that updates a file by mmapping the
> file (RW), changing the thing around, and then exiting.
>
> This did not trigger a change in the mtime of the file. Thus rsync
> didn't pick up that the file had changed.
>
> I understand that tracking every change to a RW mmapped file is
> costly, and thus unfeasable, but shouldn't then the close cause a
> mtime update?
>
> The server where this happened is running 2.6.21, so my apologies if
> this has already been corrected.
Unfortunately, this issue has not been fully fixed yet.
My last attempt (http://lkml.org/lkml/2008/1/15/202) to solve
this problem has a couple of drawbacks:
1) calling a possibly sleeping function from atomic context -
I've already corrected this;
2) there's a very special case with retouching the memory-mapped data
after a call to msync() with MS_ASYNC.
I'm still working on the latter case, but I guess that I have found a solution.
If you badly need a quick fix, I can send my working unreleased patch to you.
I reckon that your particular problem will be fixed by this patch.
Let me know if you want that.
However, if your application calls msync() with the MS_ASYNC flag,
it's better to wait a little bit more - I'll release the next version
of my solution
shortly.
>
> Roger.
>
> --
> ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
> ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
> Does it sit on the couch all day? Is it unemployed? Please be specific!
> Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2008-01-16 11:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-16 9:46 Rogier Wolff
2008-01-16 10:03 ` Dave Young
2008-01-16 10:11 ` Miklos Szeredi
2008-01-16 10:13 ` Valdis.Kletnieks
2008-01-16 11:22 ` Anton Salikhmetov [this message]
2008-01-16 12:30 ` Rogier Wolff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4df4ef0c0801160322j31645554oa6faec5cca64509d@mail.gmail.com \
--to=salikhmetov@gmail.com \
--cc=R.E.Wolff@bitwizard.nl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome