-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: TestBuildCache failing on Plan 9 #22572
Comments
This issue only happens on the plan9/386 builder running on GCE when the /tmp directory is served by ramfs. |
The issue happens because the temporary directory contains a lot of directories and is 15489 bytes. Initially, I wasn't able to reproduce this issue on my local machines, because I've increased the maximum size of 9P messages to 16 KB a while ago, mainly for performance reasons. I will send a new plan9/386 builder image for GCE, with the increased 9P message size. |
Change https://golang.org/cl/75990 mentions this issue: |
@bradfitz I've uploaded a new Plan 9 disk image for GCE. Could you deploy it? http://9legacy.org/download/go/2017-11-03/plan9-386-gce.tar.gz It should bring the plan9/386 builder back to "ok". Thanks. |
I took another look at this issue. The issue is related to how read offset is handled in ramfs when reading directories. The os.RemoveAll function calls fd.Readdirnames to read the 100 first file entries of the directory, then delete the files, then read the 100 following file entries and so on. However, after the 100 first file entries have been removed, the read offset is not valid anymore when reading the directory. When reading the 100 following files, the offset is applied to the remaining files, so a lot of files are skipped. Consequently, the content of the directory is only partially deleted, and os.RemoveAll returns the This issue doesn't happen on the Fossil file system, because Fossil ignores the read offset, except for the zero value. Fossil handles its own offset internally, and use the zero value to reset its buffer. The issue also doesn't happen when increasing the maximum size of 9P messages to 16 KB, because 16 KB is enough to hold the full content of the directory, so the subsequent calls to fd.Readdirnames read the directory from the cache. I'm not sure how to change ramfs to fix this issue yet. Also, other file servers might have the same behavior as ramfs. Instead, I'll propose a change to call |
Change https://golang.org/cl/75974 mentions this issue: |
After adding TestRemoveAllLarge to try RemoveAll on large directories in CL 75974, I've noticed that the same issue appears on nacl.
See https://storage.googleapis.com/go-build-log/7e56de12/nacl-amd64p32_c76d189d.log It seems calling |
CL 75473 added TestBuildCache. This test is failing on Plan 9.
See https://build.golang.org/log/5d60306dba3a6090b2f1f630f562ebf1ae872645
The text was updated successfully, but these errors were encountered: