On Wed, 26 Aug 2015 10:58:08 +0200
HW42 <h...@ipsumj.de> 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.

-- Andrew

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to