Mailinglist Archive: opensuse (946 mails)

< Previous Next >
Re: [opensuse] About relatime and lazytime
On 26/09/17 03:27 PM, Carlos E. R. wrote:
I'm talking of Leap. 42.1 did not have it, 42.2 has it.

I'm running a notional 42.2 with 4.13.3-2.g38f3021-default
and I just tried unmounting a Reiserfs mounted FS and cli remounting it with an
additional 'lazytime'. It is now reported to have that option -- OK.
So that makes it a "mount(1)" command OK. Bt I can't see what code in could be
in the user code that tweaks the inode. It has to be in the "mount(2)' code,
that is the kernel. It would take examining kernel source to verify. Anyone?

But it fails to answer my other question which you misinterpret.

I understand that this in in-memory. The inode is not flushed just because it
has a time field updated.

Now that makes sense in the 'preallocated" sense of a database.
What is on disk is a 'slot' in the database and the contents of the 'slot' has
changed. The allocation has not. The size has not.

Apart from that singular case the semantic get less obvious.

If I correct a spelling mistake in a document of some form, be it plain text of
OpenOffice or HTML, that is just a character inversion such as 'hte' -> 'the'
or 'adn' -> 'and', which are remarkably common, or a spelling mistake arising
from hitting an adjacent key, such as am 'i' instead of an 'o' or vice versa,
there is no change in file length. I realise that, algorithmically, the code
could read in the whole of the file, then write out the whole of the file
(possibly renaming the old on a ".bak" if you are DEC VMS obsessed. But does
it? Should it? The _file_ *is* preallocated.
But what about files that aren't on a filesystem mounted this way?

I understand that 'lazytime' amounts to a deferred flush of the inode.
I am assuming that closing the file enforces a flush; there's no way the file
semantics makes sense otherwise.

The cache is there for what purpose?
The inodes of open files are in memory and are staying in memory. PURGE-ing an
inode for an open file out of memory makes no sense.

So why have an inode cache?
There is the trivial case of directory traversal.
If I open /home/anton/MyPhotos/ByYear/2017/march/24/DFU00124.jpg
then the system has to opedeir() & readdir() internally along the way.
It also does a closedir().
Maybe, just maybe, a moment later I will view
/home/anton/MyPhotos/ByYear/2017/march/24/DFU00125.jpg
If it has cached the directory fragments and inodes then this lookup will be
fast.

We saw this progression of caching added and refined in UNIX SYSIII, SYSV, and
SUN Solaris over the years, so of course it ended up in Linux.


There are quite a few _semantic_ implications that are, in my mind, not resolved
by that man page entry.





--
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting frowned upon?


--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups