libeatmydata 130 (new formula)

[johnsonjh]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

libeatmydata 130 (new formula)

[johnsonjh]

@carlocab

It works fine - it actually has no user visible changes - it prevents datasync/fsync calls from working - instead they finish instantly.

For the canonical example:

time mysql-test-run --do-test=innodb
real 3m36.053s, user 0m42.323s, sys 0m2.844s

time eatmydata mysql-test-run --do-test=innodb
real 2m19.610s, user 0m41.939s, sys 0m2.356s

So we save more than a third of the time, but a crash or interruption in power would most likely corrupt the database - the most common use case is accelerating a CI/CD process or a "make test" where the data is ephemeral making the integrity of the data itself on disks unimportant.

The tool doesn't require root at all - it works fine as any user.

The test to verify it is actually working is what requires root on macOS.

On Linux, the simple test is:

As you can see, no sync when eatmydata is used.

On MacOS, I'd normally use dtrace to test it's working, as I would on FreeBSD and Solaris and OpenIndiana - macOS only allows DTrace calls as root (I typo's and used strace instead of sync, but that's irrelevant to illustrate the problem):

So, it works just fine on MacOS - it just can't be easily automatically tested without elevated privileges.

I could write a test in C that depends on some differences between libeatmydata sync() and OS sync() to detect if libeatmydata sync is working, but this would be more brittle and more opaque than what I have now.

Almost all of the shell script test in the formula is error checking to give different exit status levels to report exactly why it failed.

Removing these checks and giving a simple "pass" (0) or "fail" (non-zero) would probably result in a one-liner.

If you know any other system call tracing facility on MacOS that doesn't require elevated privileges, I'll use it - I'm most familiar with Solaris, and luckily MacOS includes dtrace, inherited from FreeBSD.

I checked the upstream tests - they use dtrace's dtruss too.

[carlocab]

We can just run eatmydata and check it doesn't crash, since we're unable to use dtruss.

[carlocab]

Thanks!

[johnsonjh]

Thanks!

Making good progress going through my ~/.local/bin and getting what I use all the time that's not already in brew - but should - be added. :) Hopefully the rest will be easy, and sorry to subject you to my Ruby learning experience.

[alebcay]

Thanks for your recent contributions and activity @johnsonjh! Just a few thoughts here.

[johnsonjh]

Thanks for your recent contributions and activity @johnsonjh! Just a few thoughts here.

I noticed another small problem - the oldest version of MacOS supported by Brew doesn't support the readlink -f which is used by the wrapper script, so coreutils actually would be required as a runtime dependency as well - I do have a pure POSIX shell version of this function, but it would be a 40 line patch, so depending on coreutils seems the best option.

I'll report this upstream as well.

[johnsonjh]

I'll report this upstream as well.

stewartsmith/libeatmydata#28

[johnsonjh]

Should be GTG (hopefully)

[carlocab]

LGTM. @alebcay?

[BrewTestBot]

@carlocab has triggered a merge.