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
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,
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
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
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
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 the
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 VM, would be
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_mtime
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 msync() with
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,
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 inode is
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
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 msync
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 not
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
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,
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
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
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
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,
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
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
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
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
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,
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
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-submit
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 know
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, insisted
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 calls
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 patch
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
It's
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_ctime and
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 mtime
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, mmaps file
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
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
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.
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
by
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, regardless of
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 the msync()
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:
Monday 9:04AM:
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
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
54 matches
Mail list logo
