-
Notifications
You must be signed in to change notification settings - Fork 1.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
initramfs and /etc/mtab #108
Comments
But the issue happens during 'zpool import'. No pool is imported if /etc/mtab is not a link to /proc/mounts. I did not test if mount needed /etc/mtab as well or not but judging from above comment, it looks like it would. |
Oh, I missed that the 'zpool import' bit first time around. Yes, that is strange, off hand I'm not sure what could be causing that we'll have to dig in to it. |
This issue has been addressed by the recent 'dracut' merge. |
…tion is created. (openzfs#108) Signed-off-by: satbir <satbir.chhikara@gmail.com>
This changes the memory allocator to wrap the default one and track allocations based on a tag (string literal) set in a thread-local variable. When an allocation is performed, we increment a counter based on the tag, and append the tag to the allocation. The allocation is made 8 bytes larger to store the tag. When a free is performed, if the tag is present then we decrement a counter based on the tag. We log the memory used by each tag once a minute. The performance overhead with the default settings is minimal, because only low-frequency allocations are tagged. To investigate memory usage by untagged allocations, backtrace-based tagging can be enabled, which is much more expensive even when only sampling one allocation per ~8KB allocated. Future work could include accumulating the counters in per-thread structures, to avoid the global lock on the counters, which might let us enable tagging of high-frequency allocations in production.
This port handles /etc/mtab slightly differently than the KQ port. The KQ port is designed to directly mount a filesystem with sys_mount() and then uses library calls to update mtab. This works but it's not 100% safe since the method for locking mtab has changed over time. To avoid this issue this port directly invokes the mount command which ensures that correct locking for your system is done. This might be a problem if your /etc/mtab file doesn't exist as in the case describe above. There is a --no-mtab option to mount which might be the right thing to do in this case.
The text was updated successfully, but these errors were encountered: