[Guillem Jover]
> I've suspected this would be the case all along, but as I don't use
> one of the new filesystems (due to issues like this), I never
> bothered to test it.
Note, I only tested on ext4. I have not tested on any of the new file
systems. :)
--
Happy hacking
Petter Reinholdtsen
-
Hi!
On Sun, 2013-05-19 at 15:27:32 +0200, Christoph Biedl wrote:
> Raphael Hertzog wrote...
> > The proper approach is to enhance your testing tools to use "eatmydata"
> > to really disable all fsync() and not only those of dpkg.
>
> Not a good idea. eatmydata introduces new bugs, #667965 is one
I've now tested using the dpkg patch disabling fsync(), and ran each
test three times, first comparing the normal dpkg with the
Dir::Bin::dpkg wrapper, and next comparing the patched dpkg with the
patched dpkg and the Dir::Bin::dpkg wrapper:
Sun Sep 21 09:21:28 CEST 2014 used: 750 default
Sun
[Guillem Jover]
> Hi!
Hi. :)
> You asked in the past why the current implementation is the way it
> is. A quick summary would be that, [...]
Thank you for the explanation. :)
> You should either clear the kernel cache or reboot on each iteration
> to try to get a similar initial state. The form
Hi!
On Wed, 2014-09-17 at 11:11:30 +0200, Petter Reinholdtsen wrote:
> I did some testing installing using eatmydata to see how much it could
> reduce the installation time. I used the enclosed test script to
> compare the installation time for three test setup. One is the normal
> one, the othe
Hi.
I did some testing installing using eatmydata to see how much it could
reduce the installation time. I used the enclosed test script to
compare the installation time for three test setup. One is the normal
one, the other is using dpkg-divert to divert apt-get, aptitude and
dpkg, while the th
Raphael Hertzog wrote...
> The proper approach is to enhance your testing tools to use "eatmydata"
> to really disable all fsync() and not only those of dpkg.
Not a good idea. eatmydata introduces new bugs, #667965 is one that
hit me. It causes some pain in multiarch installations, at least a
lot
[Raphael Hertzog]
> Because they care about the integrity of their system? We de not
> want to make it easy to corrupt your dpkg database.
Your comment do not make sense to me. I fail to understand how those
caring about the integrity of their system during the dpkg run would
use --force-unsafe-i
On Mon, 02 Jan 2012, Petter Reinholdtsen wrote:
> I would expect these users to also want the extra performance gained
> by dropping the left behind fsyncs()? Why should this use case want
> the remaining fsync()s in place?
Because they care about the integrity of their system? We de not want to
Thank you for the quick reply. I wish you a happy new year. :)
[Raphael Hertzog]
> This is an option that we wish it did not exist.
OK. Still do not explain to me in what situation or use case it is
useful drop fsync() for the package files while still using fsync() on
/var/lib/dpkg/updates and
Hi,
On Mon, 02 Jan 2012, Petter Reinholdtsen wrote:
> [ Mike Hommey ]
> > While this is stricly true, there are still two fsync()s occuring on each
> > package unpack, making the whole thing still slow when installing many
> > packages at a time.
> >
> > These happen for /var/lib/dpkg/updates and
Petter Reinholdtsen wrote:
> The users of --force-unsafe-io seem to be those that
[...]
In retrospect, introducing --force-unsafe-io was probably a mistake.
Making sure to always call a wrapper function that behaves just like
fsync() but can be disabled would be a maintenance burden for almost
no
[ Mike Hommey ]
> While this is stricly true, there are still two fsync()s occuring on each
> package unpack, making the whole thing still slow when installing many
> packages at a time.
>
> These happen for /var/lib/dpkg/updates and /var/lib/dpkg/tmp.ci.
[ Raphael Hertzog ]
> This is on purpose
Hi,
On Mon, 14 Feb 2011, Mike Hommey wrote:
> The manual page says:
> unsafe-io: Do not perform safe I/O operations when unpacking. Currently
> this implies not performing file system syncs before file renames, (...)
>
> While this is stricly true, there are still two fsync()s occuring on eac
Package: dpkg
Version: 1.15.8.10
Severity: normal
The manual page says:
unsafe-io: Do not perform safe I/O operations when unpacking. Currently
this implies not performing file system syncs before file renames, (...)
While this is stricly true, there are still two fsync()s occuring on each
pa
15 matches
Mail list logo
