Bug 1007619 - Review Request: eatmydata - Library and utilities designed to disable fsync
Summary: Review Request: eatmydata - Library and utilities designed to disable fsync
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Derek Higgins
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-09-13 01:16 UTC by Rino Rondan
Modified: 2015-08-24 07:45 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-08-21 16:05:29 UTC

Attachments (Terms of Use)

Description Rino Rondan 2013-09-13 01:16:27 UTC
Spec URL: <http://villadalmine.fedorapeople.org/eatmydata.spec>
SRPM URL: <http://villadalmine.fedorapeople.org/eatmydata-0.82-1.fc19.src.rpm>
Hi this is my first package and I want to someone give me a review of it in order to get this package ready.

This package contains a small LD_PRELOAD library (libeatmydata) and a couple of helper utilities designed to transparently disable fsync and friends (like open(O_SYNC)). This has two side-effects: making software that writes data safely to disk a lot quicker and making this software no longer crash safe..

Fedora Account System Username: villadalmine

Comment 1 Christopher Meng 2013-10-07 12:53:41 UTC
Why not name this package as libeatmydata?

Just because other distros named it as eatmydata?

Besides it's version number is 82, not 0.82, you should not use 0.82.

Comment 2 Eduardo Echeverria 2013-10-10 04:18:29 UTC
Yeah, @cicku are right, the package must be named like libeatmydata, since that is the upstream name, and change the version to 82 

must to do a devel package, there are unversioned so files placed directly in %{_libdir} that isn't necessary for the end-users 

See http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages

run ldconfig in shared libs https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Shared_Libraries

rpmls eatmydata-0.82-1.fc20.x86_64.rpm 
-rwxr-xr-x  /usr/bin/eatmydata
lrwxrwxrwx  /usr/lib64/libeatmydata.so
lrwxrwxrwx  /usr/lib64/libeatmydata.so.1
-rwxr-xr-x  /usr/lib64/libeatmydata.so.1.1.1
-rwxr-xr-x  /usr/libexec/eatmydata.sh
drwxr-xr-x  /usr/share/doc/eatmydata
-rw-r--r--  /usr/share/doc/eatmydata/AUTHORS
-rw-r--r--  /usr/share/doc/eatmydata/COPYING
-rw-r--r--  /usr/share/doc/eatmydata/README

- Please double-check the licenses

cat licensecheck.txt 

GPL (v2 or later)

GPL (v3 or later)

GPL (v3)

LGPL (v2.1 or later)

- Description is too long, should be 80 character per line

Comment 3 Till Maas 2013-10-21 19:42:56 UTC
Please remove NotReady from the Whiteboard when the issues in comment:2 are handled.

Comment 4 Christopher Meng 2013-11-09 16:06:04 UTC
Hmm... I think you should ask upstream for a relicensing if needed.

Comment 5 Derek Higgins 2014-12-16 16:25:20 UTC
I'd like to try and take over this package review request, I've updated the spec from Rino,

spec        : http://goodsquishy.com/downloads/eatmydata/libeatmydata.spec
source rpm  : http://goodsquishy.com/downloads/eatmydata/libeatmydata-105-1.fc20.src.rpm

Fedora Account System Username: derekh

Comment 6 Rino Rondan 2014-12-26 13:32:23 UTC
Yes, go ahead take it and follow the process, It's yours..


Comment 7 Steve Whitehouse 2015-06-15 12:06:49 UTC
Please don't add this package to Fedora. I'm not sure exactly what problem you are trying to solve in this particular case, but this is almost certainly not the right way to do it.

If you have a filesystem related performance issue with an application, then my team can help to advise on how to solve that, but ignoring O_SYNC and fsync is not the right way to do it.

Comment 8 Derek Higgins 2015-06-17 09:38:12 UTC
The motivation behind this is to speed up disposable systems, for example it can be used to speed up arbitrary CI or Unit tests where data corruption following an error doesn't matter, the test is just rerun.

In the specific example that prompted me to take over this review request, eatmydata greatly speeds up yum installs during CI tests and qcow image builds, if anything fails during either of these processes I would just rerun. I'm sure its possible to get a similar performance increase by tuning storage but for  processes that can be run on arbitary systems it may not always be possible or practical to do the appropriate tuning.

Comment 9 Miroslav Suchý 2015-07-21 14:52:31 UTC
FYI there already exist such SW in Fedora:

Comment 10 Derek Higgins 2015-08-21 16:05:29 UTC
Thanks Miroslav I didn't know about nosync,

I'm going to close this, it looks like nosync does the same thing.

Note You need to log in before you can comment on or make changes to this bug.