On Wed, 09 Jan 2008 18:41:41 EST, Rik van Riel said:
> I guess a third possible time (if we want to minimize the number of
> updates) would be when natural syncing of the file data to disk, by
> other things in the VM, would be about to clear the I_DIRTY_PAGES
> flag on the inode. That way we do
Anton Salikhmetov wrote:
2008/1/10, Rik van Riel <[EMAIL PROTECTED]>:
On Thu, 10 Jan 2008 18:56:07 +0300
"Anton Salikhmetov" <[EMAIL PROTECTED]> wrote:
However, I don't see how they will work if there has been
something like a sync(2) done after the mmap'd region is
modified and the ms
Rik van Riel wrote:
On Thu, 10 Jan 2008 18:56:07 +0300
"Anton Salikhmetov" <[EMAIL PROTECTED]> wrote:
However, I don't see how they will work if there has been
something like a sync(2) done after the mmap'd region is
modified and the msync call. When the inode is written out
as part of the
2008/1/10, Rik van Riel <[EMAIL PROTECTED]>:
> On Thu, 10 Jan 2008 18:56:07 +0300
> "Anton Salikhmetov" <[EMAIL PROTECTED]> wrote:
>
> > However, I don't see how they will work if there has been
> > something like a sync(2) done after the mmap'd region is
> > modified and the msync call. When the
On Thu, 10 Jan 2008 18:56:07 +0300
"Anton Salikhmetov" <[EMAIL PROTECTED]> wrote:
> However, I don't see how they will work if there has been
> something like a sync(2) done after the mmap'd region is
> modified and the msync call. When the inode is written out
> as part of the sync process, I_DI
2008/1/10, Rik van Riel <[EMAIL PROTECTED]>:
> On Thu, 10 Jan 2008 13:53:59 +0300
> "Anton Salikhmetov" <[EMAIL PROTECTED]> wrote:
>
> > Indeed, if msync() is called with MS_SYNC an explicit sync is
> > triggered, and Rik's suggestion would work. However, the POSIX
> > standard requires a call to m
On Thu, 10 Jan 2008 13:53:59 +0300
"Anton Salikhmetov" <[EMAIL PROTECTED]> wrote:
> Indeed, if msync() is called with MS_SYNC an explicit sync is
> triggered, and Rik's suggestion would work. However, the POSIX
> standard requires a call to msync() with MS_ASYNC to update the
> st_ctime and st_mti
2008/1/10, Jakob Oestergaard <[EMAIL PROTECTED]>:
> On Thu, Jan 10, 2008 at 03:03:03AM +0300, Anton Salikhmetov wrote:
> ...
> > > I guess a third possible time (if we want to minimize the number of
> > > updates) would be when natural syncing of the file data to disk, by
> > > other things in the
On Thu, Jan 10, 2008 at 03:03:03AM +0300, Anton Salikhmetov wrote:
...
> > I guess a third possible time (if we want to minimize the number of
> > updates) would be when natural syncing of the file data to disk, by
> > other things in the VM, would be about to clear the I_DIRTY_PAGES
> > flag on th
2008/1/10, Rik van Riel <[EMAIL PROTECTED]>:
> On Wed, 09 Jan 2008 16:06:17 -0500
> [EMAIL PROTECTED] wrote:
> > On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
> >
> > > Could you explain (using short words and simple sentences) what the
> > > exact problem is?
> >
> > It's like this:
> >
> >
2008/1/9, Rik van Riel <[EMAIL PROTECTED]>:
> On Mon, 07 Jan 2008 20:54:19 +0300
> Anton Salikhmetov <[EMAIL PROTECTED]> wrote:
>
> > This program showed that the msync() function had a bug:
> > it did not update the st_mtime and st_ctime fields.
> >
> > The program shows appropriate behavior of th
2008/1/10, Rik van Riel <[EMAIL PROTECTED]>:
> On Wed, 9 Jan 2008 23:33:40 +0100
> Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 09, 2008 at 05:06:33PM -0500, Rik van Riel wrote:
>
> > > Can we get by with simply updating the ctime and mtime every time msync()
> > > is called, regard
On Wed, 9 Jan 2008 23:33:40 +0100
Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 05:06:33PM -0500, Rik van Riel wrote:
> > Can we get by with simply updating the ctime and mtime every time msync()
> > is called, regardless of whether or not the mmaped pages were still dirty
On Wed, Jan 09, 2008 at 05:06:33PM -0500, Rik van Riel wrote:
...
> >
> > Lather, rinse, repeat
Just verified this at one customer site; they had a db that was last backed up
in 2003 :/
>
> On the other hand, updating the mtime and ctime whenever a page is dirtied
> also does not work right
Rik van Riel wrote:
On Wed, 09 Jan 2008 16:06:17 -0500
[EMAIL PROTECTED] wrote:
On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
Could you explain (using short words and simple sentences) what the
exact problem is?
It's like this:
Monday 9:04AM: System boots, database se
On Wed, 09 Jan 2008 16:06:17 -0500
[EMAIL PROTECTED] wrote:
> On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
>
> > Could you explain (using short words and simple sentences) what the
> > exact problem is?
>
> It's like this:
>
> Monday 9:04AM: System boots, database server starts up, mma
Anton Salikhmetov wrote:
Since no reaction in LKML was recieved for this message it seemed
logical to suggest closing the bug #2645 as "WONTFIX":
http://bugzilla.kernel.org/show_bug.cgi?id=2645#c15
However, the reporter of the bug, Jacob Oestergaard, insisted the
solution to be resubmitted once
On Wed, Jan 09, 2008 at 15:50:15 -0500, Rik van Riel wrote:
> > Specifically, the ctime and mtime time stamps do change
> > when modifying the mapped memory and do not change when
> > there have been no write references between the mmap()
> > and msync() system calls.
>
> As long as the ctime and
Anton Salikhmetov wrote:
> From: Anton Salikhmetov <[EMAIL PROTECTED]>
>
> I would like to propose my solution for the bug #2645 from the kernel
bug tracker:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=2645
>
> The Open Group defines the behavior of the mmap() function as follows.
>
> The st_
On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
> Could you explain (using short words and simple sentences) what the
> exact problem is?
>
> Eg.
>
> 1) program mmaps file
> 2) program writes to mmaped area
> 3) ??? <=== this part, in equally simple words :)
> 4) data loss
On Mon, 07 Jan 2008 20:54:19 +0300
Anton Salikhmetov <[EMAIL PROTECTED]> wrote:
> This program showed that the msync() function had a bug:
> it did not update the st_mtime and st_ctime fields.
>
> The program shows appropriate behavior of the msync()
> function using the kernel with the proposed
2008/1/9, Jesper Juhl <[EMAIL PROTECTED]>:
> I've only looked briefly at your patch but it seems resonable. I'll
> try to do some testing with it later.
Jesper, thank you very much for your answer!
In fact, I tested my change quite extensively using test cases for the
mmap() and msync() system ca
On 09/01/2008, Anton Salikhmetov <[EMAIL PROTECTED]> wrote:
> Since no reaction in LKML was recieved for this message it seemed
> logical to suggest closing the bug #2645 as "WONTFIX":
>
> http://bugzilla.kernel.org/show_bug.cgi?id=2645#c15
>
> However, the reporter of the bug, Jacob Oestergaard, i
On Wed, Jan 09, 2008 at 02:32:53PM +0300, Anton Salikhmetov wrote:
...
>
> This bug causes backup systems to *miss* changed files.
>
This problem is seen with both Amanda and TSM (Tivoli Storage Manager).
A site running Amanda with, say, a full backup weekly and incremental backups
daily, will
On Wed, Jan 09, 2008 at 02:32:53PM +0300, Anton Salikhmetov wrote:
> Since no reaction in LKML was recieved for this message it seemed
> logical to suggest closing the bug #2645 as "WONTFIX":
>
> http://bugzilla.kernel.org/show_bug.cgi?id=2645#c15
Thank you!
A quick run-down for those who don't
Since no reaction in LKML was recieved for this message it seemed
logical to suggest closing the bug #2645 as "WONTFIX":
http://bugzilla.kernel.org/show_bug.cgi?id=2645#c15
However, the reporter of the bug, Jacob Oestergaard, insisted the
solution to be resubmitted once more:
>>>
Please re-subm
From: Anton Salikhmetov <[EMAIL PROTECTED]>
Due to the lack of reaction in LKML I presume the message was lost
in the high traffic of that list. Resending it now with the addressee changed
to the memory management mailing list.
I would like to propose my solution for the bug #2645 from the kernel
27 matches
Mail list logo
