Skip to content
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

Closed
behlendorf opened this issue Feb 19, 2011 · 3 comments
Closed

initramfs and /etc/mtab #108

behlendorf opened this issue Feb 19, 2011 · 3 comments

Comments

@behlendorf
Copy link
Contributor

Something odd. From my laptop booted into 2.6.37.1 and ZFS modules 
loaded, I can import the KQI created pool. But inside my initramfs, it 
fails to import the pool. 'zpool' command just comes out without 
finding anything. zpool list doesn't show any pools. /dev/sda, /dev/ 
sda1, /dev/sda2 are present. /dev/sda2 is where the rpool is. 
Where do we go from here? 
EDIT: got the clue. It looks like zpool in Brian's code is looking 
for /etc/mtab for some reason AND not cribbing about it though. Once I 
created a link from /proc/mounts to /etc/mtab, it imported the pool 
correctly. Something to fix. 

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.

@devsk
Copy link

devsk commented Feb 19, 2011

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.

@behlendorf
Copy link
Contributor Author

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.

@behlendorf
Copy link
Contributor Author

This issue has been addressed by the recent 'dracut' merge.

@mickg10 mickg10 mentioned this issue Nov 6, 2015
richardelling pushed a commit to richardelling/zfs that referenced this issue Oct 15, 2018
…tion is created. (openzfs#108)

Signed-off-by: satbir <satbir.chhikara@gmail.com>
sdimitro pushed a commit to sdimitro/zfs that referenced this issue Feb 14, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants