Using the testing method from #17 for the package oxygen-icon-theme
(5890 mostly small files), tested on a 5400 RPM laptop harddisk
formatted with ext4.
dpkg 1.15.5.6ubuntu4:
unpack: 37s
real: 53s
dpkg 1.15.5.6ubuntu5~ppa1:
unpack: 5s
real: 22s
Also tested on a RAID 0 array c
Ok, looked at Colin's backport:
It's the right way to do it; and I suspect this is true for all Unixish
OSes with all filesystems, whether or not they have synchronous sync().
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installation times
https://bugs.laun
What benefit is provided by all the fsync action?
Without it, a power-failed install may have zero-length or wrong-content
files.
With it, a power-failed install still has a broken package -- each
individual file may be fully there or fully not-there, but there will be
missing files.
It doesn't
dpkg from Colin Watsons PPA solved the problem: I installed "Blender"
and the unpacking phase of the 10Mb package took less than a second. And
I experience no more rattling disks when installing packages.
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installa
I wonder if my problem is related to this bug - I am observing excessive
harddisk activity in the unpack phase of package installations on all three
Lucid systems:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/580537
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and
Test on ext3 (Karmic upgraded to Lucid), 5400rpm notebook hd. Note that
i think in addition to dropping the caches, we have to sync before
running the test to get somewhat stable results.
Commands used (as root):
sync; echo 3 > /proc/sys/vm/drop_caches; time dpkg -i
/var/cache/apt/archives/open
I ran some tests on my Dell Latitude D430, which has ext4 and a ridiculously slo
w hard disk. I tested with:
$ echo 3 | sudo tee /proc/sys/vm/drop_caches; sudo dpkg -i
/var/cache/apt/archives/openoffice.org-common_1%3a3.2.0-7ubuntu4_all.deb
| ts
old dpkg:
openoffice.org-common: 56s unpack, 25s co
Colin-
Poke me when you have an install media ready to test. That's my
primary use case, and I'll gladly help test that.
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installation times
https://bugs.launchpad.net/bugs/570805
You received this bug notificati
I would appreciate it if people affected by this bug could test the dpkg
package from:
https://launchpad.net/~cjwatson/+archive/ppa
This is probably easier to test if you're seeing problems with dpkg
performance after installation, although I do plan to hack it into an
installation environment
Note that for the install case where corruption does not matter, a
export LD_PRELOAD=./libeatmydata.so
should bring performance back to normal (or even above) in a very simple way.
See http://www.flamingspork.com/projects/libeatmydata/
--
[regression] dpkg fsync cause massive regression in Ubunt
Am 05/05/10 15:53, schrieb Jean-Baptiste Lallement:
> ** Bug watch added: Linux Kernel Bug Tracker #15910
> http://bugzilla.kernel.org/show_bug.cgi?id=15910
>
> ** Also affects: linux via
> http://bugzilla.kernel.org/show_bug.cgi?id=15910
> Importance: Unknown
> Status: Unknown
** Bug watch added: Linux Kernel Bug Tracker #15910
http://bugzilla.kernel.org/show_bug.cgi?id=15910
** Also affects: linux via
http://bugzilla.kernel.org/show_bug.cgi?id=15910
Importance: Unknown
Status: Unknown
--
[regression] dpkg fsync cause massive regression in Ubuntu Serve
Sorry, "Jean-Baptiste Lallement"
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installation times
https://bugs.launchpad.net/bugs/570805
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bug
Jean-Baptists Lallement tested this behaviour and found that ext4's
guarantee seems to be ... not so much of a guarantee in reality. I
asked him to file it on bugzilla.kernel.org.
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installation times
https://bugs.
The explanation in the release notes is confusing. First of all, as
Jakob wrote above, ext4 starting with 2.6.30 provides similar behavior
to ext3 with data=ordered. So, it is not clear why fsync() is necessary
on ext4, but not on ext3.
More importantly, the default mode for ext3 was changed to
da
I second that, i love to see some background info!
But it looks like either the release notes or the ext4 documenation
needs updating:
===
Release notes
===
`ext4` does not guarantee atomic renames of
new files over existing files in the event of a
power failure shortly after the rename
===
ext4
Looks great. Very informative, Colin.
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installation times
https://bugs.launchpad.net/bugs/570805
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubun
I've release-noted this as follows (feel free to tweak from here):
== Default file system; package manager performance ==
The default file system for installations of Ubuntu 10.04 LTS is `ext4`,
the latest version in the popular series of Linux extended file systems.
`ext4` includes a number of p
** Tags added: iso-testing
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installation times
https://bugs.launchpad.net/bugs/570805
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mail
Phillip-
Thanks for the link.
The cause, is in fact, the same (fsync's in dpkg).
The solution, though, might be subtlety different. As I've said above,
I can understand and agree with the change in behavior for
updates/upgrades on a running system.
This current bug, though, is about what's goi
This appears to be a duplicate of bug #537241.
--
[regression] dpkg fsync cause massive regression in Ubuntu Server and Alternate
installation times
https://bugs.launchpad.net/bugs/570805
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Thierry-
Regarding upgrades, I think I agree with the current design. Data
integrity on a running system is of paramount importance.
New installs, though, are a different beast, in my opinion, since a
failure would necessitate a reinstall anyway.
** Summary changed:
- [regression] dpkg fsync c
22 matches
Mail list logo
