Hello! Thanks for looking into this. It is probably specific to UFS (not ZFS) and maybe only when soft-updates are enabled (which is default, and I think enabled on the buildds). It defers writing of some metadata to disk until the next sync or after some time has elapsed. > [Andreas Henriksson] > > a/ working around a really serious potential data loss bug in kfreebsd > > b/ hiding a race in the testsuite by making it less likely to trigger I think this is a kernel bug, but shouldn't cause data loss. I wouldn't suggest working around it in libarchive, unless you are in a hurry to have it built again and don't mind carying that patch. It may take some time to produce a test case for upstream FreeBSD, fix it, and get our buildds running a fixed kernel. > > Neither really sounds like we're getting the correct fix, but maybe > > I'm wrong. > > Would be useful if some kFreeBSD expert would comment on this. :) If stat or access system calls return old data, instead of what's in a cache to be written out, that certainly sounds like a bug. > suspect posix require that open/write/close should cause a following > access() to see the freshly created file, but can not quite which > requirement that would be. :) Sanity? Common sense? POLA? It should be even quicker to return from the cache than read some outdated metadata from disk... Regards, -- Steven Chamberlain steven@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature