[EMAIL PROTECTED] wrote:
But if you didn't notice until now, then the current implementation
must be pretty reasonable for you use as well.
Oh, I definitely noticed. As soon as I tried to port my application
to 2.6, it broke - as evidenced by my complaints last year. The
current solution is
> But if you didn't notice until now, then the current implementation
> must be pretty reasonable for you use as well.
Oh, I definitely noticed. As soon as I tried to port my application
to 2.6, it broke - as evidenced by my complaints last year. The
current solution is simple - since it's runni
[EMAIL PROTECTED] wrote:
Linux _will_ write all modified data to permanent storage locations.
Since 2.6.17 it will do this regardless of msync(). Before 2.6.17 you
do need msync() to enable data to be written back.
But it will not start I/O immediately, which is not a requirement in
the standar
> Linux _will_ write all modified data to permanent storage locations.
> Since 2.6.17 it will do this regardless of msync(). Before 2.6.17 you
> do need msync() to enable data to be written back.
>
> But it will not start I/O immediately, which is not a requirement in
> the standard, or at least
On 27 Mar 2007 16:09:33 -0400
[EMAIL PROTECTED] wrote:
> What part of "The msync() function writes all modified data to
> permanent storage locations [...] For mappings to files, the msync()
> function ensures that all write operations are completed as defined
> for synchronised I/O data integrity
> > Suggest you use msync(MS_ASYNC), then
> > sync_file_range(SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE).
>
> Thank you; I didn't know about that. And I can handle -ENOSYS by falling
> back to the old behavior.
>
> > We can fix your application, and we'll break someone else's.
>
> If yo
> Suggest you use msync(MS_ASYNC), then
> sync_file_range(SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE).
Thank you; I didn't know about that. And I can handle -ENOSYS by falling
back to the old behavior.
> We can fix your application, and we'll break someone else's.
If you can point to an
On 27 Mar 2007 15:24:52 -0400
[EMAIL PROTECTED] wrote:
> > * MS_ASYNC does not start I/O (it used to, up to 2.5.67).
>
> Yes, I noticed. See
> http://www.ussg.iu.edu/hypermail/linux/kernel/0602.1/0450.html
> for a bug report on the subject February 2006.
Suggest you use msync(MS_ASYNC), then
sy
> * MS_ASYNC does not start I/O (it used to, up to 2.5.67).
Yes, I noticed. See
http://www.ussg.iu.edu/hypermail/linux/kernel/0602.1/0450.html
for a bug report on the subject February 2006.
That's why this application is still running on 2.4.
As I mentioned at the time, the SUS says:
(http://op
On Tue, 27 Mar 2007 20:55:51 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> It's actually wrong about FADV_DONTNEED, which I think doesn't start
> writeout either.
case POSIX_FADV_DONTNEED:
if (!bdi_write_congested(mapping->backing_dev_info))
fil
> > I agree that msync(MS_ASYNC) has no semantics if time is ignored.
> > But it's a useful way to tell the OS that the page is not going
> > to be dirtied again.
>
> Just to clarify, here's the header comment for sys_msync():
>
> /*
> * MS_SYNC syncs the entire file - including mappings.
> *
>
> > Yes, this will make msync(MS_ASYNC) more heavyweight again. But if an
> > application doesn't want to update the timestamps, it should just omit
> > this call, since it does nothing else.
>
> Er... FWIW, I have an application that makes heavy use of msync(MS_ASYNC)
> and doesn't care about ti
> Yes, this will make msync(MS_ASYNC) more heavyweight again. But if an
> application doesn't want to update the timestamps, it should just omit
> this call, since it does nothing else.
Er... FWIW, I have an application that makes heavy use of msync(MS_ASYNC)
and doesn't care about timestamps. (
> that's simpler ;) Is it correct enough though? The place where it will
> become inaccurate is for repeated modification via an established map. ie:
>
> p = mmap(..., MAP_SHARED);
> for ( ; ; )
> *p = 1;
>
> in which case I think the timestamp will only get updated on
On Tue, 27 Mar 2007 11:23:06 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > > > But Peter Staubach says a RH custumer has files written thorugh mmap,
> > > > > which are not being backed up.
> > > >
> > > > Yes, I expect the backup problem is the major real-world hurt arising
> > > > from
> > > > But Peter Staubach says a RH custumer has files written thorugh mmap,
> > > > which are not being backed up.
> > >
> > > Yes, I expect the backup problem is the major real-world hurt arising from
> > > this bug.
> > >
> > > But I expect we could adequately plug that problem at munmap()-ti
On Tue, 27 Mar 2007 10:28:16 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > But Peter Staubach says a RH custumer has files written thorugh mmap,
> > > which are not being backed up.
> >
> > Yes, I expect the backup problem is the major real-world hurt arising from
> > this bug.
> >
> > B
> > But Peter Staubach says a RH custumer has files written thorugh mmap,
> > which are not being backed up.
>
> Yes, I expect the backup problem is the major real-world hurt arising from
> this bug.
>
> But I expect we could adequately plug that problem at munmap()-time. Or,
> better, do_wp_pag
On Tue, 27 Mar 2007 10:03:41 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> But Peter Staubach says a RH custumer has files written thorugh mmap,
> which are not being backed up.
Yes, I expect the backup problem is the major real-world hurt arising from
this bug.
But I expect we could adequat
> > > There is surely no need to duplicate all that.
> >
> > Yeah, we could teach generic_writepages() to conditionally not submit
> > for io just test/clear pte dirtyness.
> >
> > Maybe that would be somewhat cleaner, dunno.
> >
> > Then there are the ram backed filesystems, which don't have di
On Tue, 27 Mar 2007 09:36:50 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > There is surely no need to duplicate all that.
>
> Yeah, we could teach generic_writepages() to conditionally not submit
> for io just test/clear pte dirtyness.
>
> Maybe that would be somewhat cleaner, dunno.
>
>
> > > clear_page_dirty_for_io() already does that.
> > >
> > > So we should be able to test PageDirtiedByWrite() after running
> > > clear_page_dirty_for_io() to discover whether this page was dirtied via
> > > MAP_SHARED, and then update the inode times if so.
> >
> > What do you need the page f
On Tue, 27 Mar 2007 08:55:40 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > > > This patch makes writing to shared memory mappings update st_ctime and
> > > > > st_mtime as defined by SUSv3:
> > > >
> > > > Boy this is complicated.
> > >
> > > You tell me?
> > >
> > > > Is there a simple
> > > > This patch makes writing to shared memory mappings update st_ctime and
> > > > st_mtime as defined by SUSv3:
> > >
> > > Boy this is complicated.
> >
> > You tell me?
> >
> > > Is there a simpler way of doing all this? Say, we define a new page flag
> > > PG_dirtiedbywrite and we do Set
On Mon, 26 Mar 2007 23:43:08 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > This patch makes writing to shared memory mappings update st_ctime and
> > > st_mtime as defined by SUSv3:
> >
> > Boy this is complicated.
>
> You tell me?
>
> > Is there a simpler way of doing all this? Say, w
On Mon, 26 Mar 2007 16:10:09 -0500
Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 26, 2007 at 02:00:36PM -0700, Andrew Morton wrote:
> > On Sun, 25 Mar 2007 23:10:21 +0200
> > Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> > > This patch makes writing to shared memory mappings update st_c
> > This patch makes writing to shared memory mappings update st_ctime and
> > st_mtime as defined by SUSv3:
>
> Boy this is complicated.
You tell me?
> Is there a simpler way of doing all this? Say, we define a new page flag
> PG_dirtiedbywrite and we do SetPageDirtiedByWrite() inside write()
On Mon, Mar 26, 2007 at 02:00:36PM -0700, Andrew Morton wrote:
> On Sun, 25 Mar 2007 23:10:21 +0200
> Miklos Szeredi <[EMAIL PROTECTED]> wrote:
>
> > This patch makes writing to shared memory mappings update st_ctime and
> > st_mtime as defined by SUSv3:
>
> Boy this is complicated.
>
> Is there
On Sun, 25 Mar 2007 23:10:21 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> This patch makes writing to shared memory mappings update st_ctime and
> st_mtime as defined by SUSv3:
Boy this is complicated.
Is there a simpler way of doing all this? Say, we define a new page flag
PG_dirtiedbywri
From: Miklos Szeredi <[EMAIL PROTECTED]>
Changes:
v4:
o rename test_clear_page_modified to page_mkclean_noprot
o clean up page_mkclean_noprot
o don't set AS_CMTIME from fault handler, since that also sets the PTE dirty
o only update c/mtime in munmap, if file is not mapped any more
o cleanups
30 matches
Mail list logo
