Andrew Ayer:
> On Wed, 26 Aug 2015 10:58:08 +0200
> HW42 <> wrote:
>>> Errors from close are not properly reported.
>> Probably don't hurt. Most programs ignore them anyway.
> I think close() only fails if there's a disk error or you run out of
> disk space/quota.  Neither of these should happen during a normal build.
>>> fsync is not implemented.
>> Beside of timing this should not make a difference as long the maschine
>> don't crash. (I think that's what libeatmydata is doing via LD_PRELOAD).
>> And we are building on tmpfs anyway (I don't know if fsync does anything
>> on tmpfs).
> Right.  To be clear, fsync() and fdatasync() still report success with
> disorderfs - they just don't do anything.
>>> xattrs are not implemented.
>> Probably only hurts for packages which need to handle those and have
>> test cases for it. (e.g. rsync, rdiff-backup, ...)
> I'm guessing that only a minority of packages would be affected.
> But, implementing xattrs turned out to be trivial, so I just released
> 0.2.0 with xattr support.  The Debian package is ready for someone to
> upload.


>> Can packages contain files with xattrs and if yes does this anybody?
>>> Locks are not propagated to the underlying filesystem.
>> This will hurt when a build system relies on them. I have no idea how
>> many are affected by this.
> Locks still work within the overlay filesystem itself.  However, if one
> process is accessing the underlying filesystem directly, and another
> process is accessing through disorderfs, they won't see each others'
> locks.  Since the build will only access through disorderfs, the lack
> of lock propagation shouldn't affect builds.

Ah ok. Then I think nothing _should_ break builds (with the updated

Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to