Re: Spurious "file has changed on disk" warnings on Linux
- First Post
- Replies
- Stats
-
Go to
- ----- 2024 -----
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
Justin Vallon <vallon(a)mindspring.com> writes in xemacs-beta(a)xemacs.org:
On Fri, 6 Nov 1998, Kyle Jones wrote:
> > > Fix #2: Change order of close and stat
> >
> > This would seem to be the correct solution. On other systems it should
> > not make any difference. The only thing is, why wasn't it done before?
>
> stat() is relatively expensive compared to fstat(). Also, it
> is surprising (to me) that close() would fiddle with the file
> modtime, given that close() does no implicit flushing of data.
I seem to remember somewhere that NFS writes may be postponed until
close().
This brings back bad memories of old flame wars. I don't think NFS
will do this, but I know AFS can raise errors on close. If Dejanews
has restored enough old netnews, there should be megabytes on this
topic in the old archives.
That is, close() may give errors such as disk full, etc, because
for performance reasons, write() is only done locally and disk allocation
is not done until close [or a later write].
Something like that, as I recall.
Justin Vallon
Saturday, 7 November
Sat, 7 Nov
9:09 a.m.
New subject: Spurious "file has changed on disk" warnings on Linux
On 7 Nov 1998, SL Baur wrote:
Justin Vallon <vallon(a)mindspring.com> writes in
xemacs-beta(a)xemacs.org:
> I seem to remember somewhere that NFS writes may be postponed until
> close().
This brings back bad memories of old flame wars. I don't think NFS
will do this, but I know AFS can raise errors on close. If Dejanews
has restored enough old netnews, there should be megabytes on this
topic in the old archives.
> That is, close() may give errors such as disk full, etc, because
> for performance reasons, write() is only done locally and disk allocation
> is not done until close [or a later write].
Something like that, as I recall.
HP/UX 10.20, man close:
ERRORS
close() fails if the any of following conditions are encountered:
...
[ENOSPC] Not enough space on the file system. This error
can occur when closing a file on an NFS file
system. [When a write() system call is executed
on a local file system and if a new buffer needs
to be allocated to hold the data, the buffer is
mapped onto the disk at that time. A full disk is
detected at this time and write() returns an
error. When the write() system call is executed
on an NFS file system, the new buffer is allocated
without communicating with the NFS server to see
if there is space for the buffer (to improve NFS
performance). It is only when the buffer is
written to the server (at file close or the buffer
is full) that the disk-full condition is
detected.]
So, it appears that at least the HP NFS write() call can be cached and the
cache is not write-through. Hence, a flush would most likely be required,
or else stat() may be using a stale last-modify time.
-Justin
vallon(a)mindspring.com
Charles G Waldman
Saturday, 7 November
Sat, 7 Nov
3:14 p.m.
New subject: Spurious "file has changed on disk" warnings on Linux
SL Baur writes:
Justin Vallon <vallon(a)mindspring.com> writes in
xemacs-beta(a)xemacs.org:
> On Fri, 6 Nov 1998, Kyle Jones wrote:
>> stat() is relatively expensive compared to fstat(). Also, it
>> is surprising (to me) that close() would fiddle with the file
>> modtime, given that close() does no implicit flushing of data.
> I seem to remember somewhere that NFS writes may be postponed until
> close().
This brings back bad memories of old flame wars. I don't think NFS
will do this, but I know AFS can raise errors on close. If Dejanews
has restored enough old netnews, there should be megabytes on this
topic in the old archives.
Certainly I don't want to touch off any flame wars, but the current
behaviour makes XEmacs basically unusable on Linux with NFS-mounted
filesystems. I did a bit of Dejanews searching but didn't come up
with anything relevant searching for "NFS", "modtime" or "changed
on
disk". Do you remember what was the upshot of the previous
discussions on this?
The simple-minded experiment of adding:
printf("st.st_mtime=%d, b->modtime=%d\n", st.st_mtime, b->modtime);
before line 3690 in fileio.c will show that in fact the buffer is
recording a stale modtime, but only when visiting a file on an NFS
filesystem. It's got to be fixed, one way or the other - either by
fixing autoconf and the s&m files so that fsync() gets done, or else
by doing close()/stat() rather than fstat()/close() and accepting the
added expense of the stat.
9512
days inactive
9512
days old
2 comments
3 participants
tags (0)
participants (3)
-
Charles G Waldman -
Justin Vallon -
SL Baur