Install udev rules to /lib/udev/rules.d #356
Conversation
|
I agreed, but I don't really have time to work on it at the moment either. I'm trying to focus on some of the remaining core issues. |
|
Ok, I will try write a patch for /lib/udev/rules.d, what do you think about the dracut 90-zfs rule? |
|
OK, I couldn't resist and put together a quick patch which I'm not fond of. Unfortunately, we can't simply use libdir instead of sysconfdir because it can be defined as /lib64 not /lib. I am instead using bindir which is defined by the the packaging as /lib/udev since the only non-sbin binaries needed are for udev. Unfortunately, this scheme falls apart when not building packages and bindir is defined as /bin. Anyway, this patch at least shows roughly what needs to change. dc71219478c5fe835cda19dd3636ec636be32049 As for the dracut 90-zfs rule it should be OK to installing it along with the usual udev rules. You would just need to make sure dracut's module-setup.sh is also updated to reference the new location. It might also cause some heartburn for some of the init scripts if they don't handle the case when the module are already loaded (they should). |
|
I was just checking how other people do this, lvm2 has additional prefixes for udev. Example: |
|
I read in the commit comment "Unfortunately, this scheme falls apart when not building packages and bindir is defined as /bin.". Are there any default ./configure arguments for package building? The AUR archlinux package just sets |
|
Adding an additional prefixes for udev does seem like the cleanest solution. |
|
It really just means you need to pass the following paths to configure which is what the rpm/deb packages do. Although I much prefer the idea of adding additional udev prefixes even if it is more work. ./configure --prefix=/ --bindir=/lib/udev --libexecdir=/usr/libexec --datadir=/usr/share |
|
I can't work out what is wrong with c19b315, I am pretty sure everything in |
|
A few comments about c19b315f404a80078d019fc4da619c442bc154fa .
|
|
I have turned this into a pull request with my changes for both 90-zfs and udev rules. Please remember to run ./autogen.sh. I have some questions about the dracut support, I do not have a distro which uses dracut so I cannot test.
|
|
Thanks for working on this and taking care of my concerns above. I've merged it with just a few minor tweaks for things which were originally overlooked. Merged with a few minor tweaks.
|
|
Reopening. I didn't mean to close this entirely since we still have the dracut changes pending. Concerning your questions I'll going to try and pull Pendor in to this discussion since I'm sure he's the most familiar with dracut.
|
|
By default dracut_install will fall down to inst_binary which looks in {/bin, /sbin, /usr/bin, /usr/sbin} in that order. If the binary isn't in one of those spots, the full path must be specified in the dracut_install call. That will probably necessitate pre-processing module-setup.sh or else modifying it at install to honor the right prefix value. I think it would also require specifying the path where the files should be installed in the initrd (which can be done with a second argument to dracut_install). Default just drops them in /bin, but either the udev rules would need to be modified when the initrd was built or else the binaries would need to be installed at the same paths as they are on the live system. I don't have sas_switch_id in my initrd's, but I'm running very simple storage configs. I don't see any harm in having it. Subject to the above pathing caveats, dracut_install will be bright enough to pull in any additional libs it might need automatically. |
|
I have rebased and fixed dracut, (well, I think its fixed. I am unable to test). 0462030 Fixes a bug where the init.d files wouldn't work depending on the configure options used to build zfs. I included it here to save making another pull request. prefix=/usr/local
exec_prefix=${prefix}
ZFS="${exec_prefix}/sbin/zfs"
ZPOOL="${exec_prefix}/sbin/zpool"
ZPOOL_CACHE="${prefix}/etc/zfs/zpool.cache"Unfortunately I didn't catch this before because I set all the paths so this never happened. |
|
Yes, I missed this as well. I've pulled fce563d but can you please fix the prefix issue a slightly different way. This is the exact reason for the sed you asked about earlier in rules.d/Makefile.am. See commit b9f27ee. It would be best to fix this the same way, then we don't need to define the prefix and exec_prefix variables in the init scripts. |
|
Actually I took a first swing at updating your patchs to use the preferred autoconf approach. The updates patches can be found here. They are basically working however they need most testing to ensure everything is exactly right. This build system work is always trickier than it first appears. |
|
Brian, I gave your branch a shot in the Gentoo ebuild. Looks like something's trying to I'll try to take a closer look in the morning and see if I can get it working. Spent more time than I would have liked this evening getting the trunk builds of SPL & ZFS building in my ebuilds (almost exclusively my fault, not trunk's...). |
|
The issue is: pkgdracut_DATA = $(top_srcdir)/dracut/90zfs/module-setup.sh
dist_pkgdracut_SCRIPTS = \
$(pkgdracut_DATA) \module-setup.sh is installed with both pkgdracut_DATA and dist_pkgdracut_SCRIPTS. A solution could be to rename pkgdracut_DATA to something else, and create a second pkgdracutdir variable to use. + pkgdracutinstalldir = $(pkgdracutdir)
- pkgdracut_DATA = $(top_srcdir)/dracut/90zfs/module-setup.sh
+ pkgdracutinstalldir_DATA = $(top_srcdir)/dracut/90zfs/module-setup.sh
dist_pkgdracut_SCRIPTS = \
- $(pkgdracut_DATA) \
- $(pkgdracut_DATA):
+ $(pkgdracutinstalldir_DATA):I can't think of any simpler solution. |
|
OK, try this. I force updated the branch and made a few fixes. The current branch works well for me but I want to make sure your both happy with it before I merge it. I'm very wary of tinkering with the build system this much without significant testing, it's far to easy to accidentally miss something. That said, I think this is definitely any improvement. |
|
HEAD from the udev branch built & booted fine on Gentoo. Looks good to me. |
|
Looks fine to me also. |
|
Merged in to master, thanks for helping me test this. |
For small objects the Linux slab allocator has several advantages over its counterpart in the SPL. These include: 1) It is more memory-efficient and packs objects more tightly. 2) It is continually tuned to maximize performance. Therefore it makes sense to layer the SPLs slab allocator on top of the Linux slab allocator. This allows us to leverage the advantages above while preserving the Illumos semantics we depend on. However, there are some things we need to be careful of: 1) The Linux slab allocator was never designed to work well with large objects. Because the SPL slab must still handle this use case a cut off limit was added to transition from Linux slab backed objects to kmem or vmem backed slabs. spl_kmem_cache_slab_limit - Objects less than or equal to this size in bytes will be backed by the Linux slab. By default this value is zero which disables the Linux slab functionality. Reasonable values for this cut off limit are in the range of 4096-16386 bytes. spl_kmem_cache_kmem_limit - Objects less than or equal to this size in bytes will be backed by a kmem slab. Objects over this size will be vmem backed instead. This value defaults to 1/8 a page, or 512 bytes on an x86_64 architecture. 2) Be aware that using the Linux slab may inadvertently introduce new deadlocks. Care has been taken previously to ensure that all allocations which occur in the write path use GFP_NOIO. However, there may be internal allocations performed in the Linux slab which do not honor these flags. If this is the case a deadlock may occur. The path forward is definitely to start relying on the Linux slab. But for that to happen we need to start building confidence that there aren't any unexpected surprises lurking for us. And ideally need to move completely away from using the SPLs slab for large memory allocations. This patch is a first step. NOTES: 1) The KMC_NOMAGAZINE flag was leveraged to support the Linux slab backed caches but it is not supported for kmem/vmem backed caches. 2) Regardless of the spl_kmem_cache_*_limit settings a cache may be explicitly set to a given type by passed the KMC_KMEM, KMC_VMEM, or KMC_SLAB flags during cache creation. 3) The constructors, destructors, and reclaim callbacks are all functional and will be called regardless of the cache type. 4) KMC_SLAB caches will not appear in /proc/spl/kmem/slab due to the issues involved in presenting correct object accounting. Instead they will appear in /proc/slabinfo under the same names. 5) Several kmem SPLAT tests needed to be fixed because they relied incorrectly on internal kmem slab accounting. With the updated test cases all the SPLAT tests pass as expected. 6) An autoconf test was added to ensure that the __GFP_COMP flag was correctly added to the default flags used when allocating a slab. This is required to ensure all pages in higher order slabs are properly refcounted, see ae16ed9. 7) When using the SLUB allocator there is no need to attempt to set the __GFP_COMP flag. This has been the default behavior for the SLUB since Linux 2.6.25. 8) When using the SLUB it may be desirable to set the slub_nomerge kernel parameter to prevent caches from being merged. Original-patch-by: DHE <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Signed-off-by: Prakash Surya <[email protected]> Signed-off-by: Tim Chase <[email protected]> Signed-off-by: DHE <[email protected]> Signed-off-by: Chunwei Chen <[email protected]> Closes openzfs#356
For small objects the Linux slab allocator should be used to make the most efficient use of the memory. However, large objects are not supported by the Linux slab and therefore the SPL implementation is preferred. A cutoff of 16K was determined to be optimal for architectures using 4K pages. Signed-off-by: Brian Behlendorf <[email protected]> Signed-off-by: DHE <[email protected]> Issue openzfs#356 Closes openzfs#379
When we initiate a checkpoint, in `ZettaCache::flush_checkpoint()`, we need to wait for in-progress reads and writes, to ensure that they are committed before the checkpoint is committed. The problem is that after we wait for in-progress i/o, more i/o's can be initiated before we acquire the zettacache state lock and take the checkpoint. By injecting delays and panic's, I was able to cause the agent to die after the checkpoint was committed (i.e. the superblocks were written) but before all the writes that should be part of it were completed. When those blocks are subsequently read, a checksum error is detected and the zettacache is healed. This commit solves the problem by waiting for in-progress i/o (`ZettaCacheState::outstanding_reads/_writes`) while holding the state lock. This increases the state lock hold time, although the lockless wait still reduces the hold time somewhat. This is not great for performance, but it's a simple fix.
Appears to corrupt pool, take safe option until it can be investigated. Signed-off-by: Jorgen Lundman <[email protected]>
From what I understand is that udev now installs rules into /lib/udev/rules.d by default, leaving /etc/udev/rules.d for user rules and overrides only. I would write a patch myself, but this automake stuff doesn't make sense to me.
Perhaps also the 90-zfs rule in dracut should be moved to somewhere else also, this isn't dracut specific, it would be useful to use in mkinitcpio for archlinux. Maybe it could be installed somewhere generic and referenced there from both mkinitcpio and dracut.