[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-tar] Extraction performance problem

From: Jakob Bohm
Subject: Re: [Help-tar] Extraction performance problem
Date: Fri, 13 Feb 2015 16:17:59 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 06/02/2015 17:39, Paul Eggert wrote:
Jakob Bohm wrote:
It is not as much a direct requirement as an indirect one.

Specifically, for local filesystems, there is no other way in
which a user mode application (such as a DB engine) can control
when its data has reached stable storage after closing the file

There is no indirect requirement either.  User mode applications that
care about stable data are supposed to use fdatasync or fsync or
something like that. 'close' is not required to ensure that the data
have hit stable storage, and on most operating systems I believe 'close'
does not do that.  This is for obvious performance reasons.  The
GNU/Linux man page for 'close', for example, says "A successful close
does not guarantee that the data has been successfully saved to disk, as
the kernel defers writes."

If some virus scanners have trouble in this area, that's something that
needs to be fixed in the virus scanners; it shouldn't require changing
all other applications to work around the virus scanners' performance

I am afraid this is an observation of the general behavior of this class
of programs.  The primary reason for this behavior is that the kernels
they run on top of restrict the options for where in the VFS processing
chain they can be called to do their work.

I have actually tried one virus scanner that forks off its actual
scanning of freshly created files so it doesn't hold back close() calls.
The result: Failed software builds as the linker's attempt to open
recently created .o files conflict with the virus scanner still checking
the newly created code for Thompson attacks (it's a millisecond level
race condition and doesn't happen on each run, but it shows the dangers
of trying not to slow down close()).

Another reason is that it would be a severe security vulnerability if
someone could upload a piece of malware to a boot-executed location,
then crash the machine to prevent the virus scanner from seeing the
bad code before it is run during the next boot (before the virus
scanner itself is loaded).


Jakob Bohm, CIO, Partner, WiseMo A/S.
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]