Summary: | sys-fs/lvm2-2.02.97 /etc/init.d/device-mapper does not support multi-line volumes in /etc/dmtab | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mads <mads> |
Component: | [OLD] Core system | Assignee: | Robin Johnson <robbat2> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | agk, cardoe, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
new /etc/init.d/device-mapper, non-working
new /etc/init.d/device-mapper, working new device-mapper init.d in patch form |
Description
Mads
2012-10-13 19:59:58 UTC
A solution would be to change the script to create a temporary file for each volume, and then call dmsetup create <volname> <tempfile> in the init script. I'm not exactly sure how this should be solved if a temp file is not possible... I figured out that it was possible to create multi-line volumes in one dmsetup command. The example given in the initial description can be created like:
> echo -e "0 1028160 linear /dev/hda 0\n1028160 3903762 linear /dev/hdb 0" | \
> dmsetup create volname /dev/stdin
I haven't managed yet to edit the init script to reflect this yet, I suspect it will need a restructure of the get_new_dm_volumes function.
patches welcome Created attachment 336058 [details] new /etc/init.d/device-mapper, non-working Ah, I forgot about this one, thank you for reminding me! I kinda got an idea of how it could be solved, but I hit a road block that I might need some help with. > # /etc/init.d/device-mapper start > /etc/init.d/device-mapper: line 40: syntax error near unexpected token `<' > /etc/init.d/device-mapper: line 40: ` done < <(grep -v -e '^[[:space:]]*\(#\|$\)' /etc/dmtab)' > * ERROR: device-mapper failed to start The updated function get_new_dm_volumes tries to create a associative array "dmsetup_cmds" where the keys are volnames:, and values are the finished dmsetup command. The array building cannot take place in a subshell which are done in the original script (line 29&30) because then array variable would not be available in the for loop afterward (not the same process). This can be solved by using process substitution as I have done in the attached script, but OpenRC won't parse it, giving that error message I pasted earlier... I don't know if my escaping in line 35 is correct, I haven't come so far that I've been able to test it. But it seemingly puts together the dmsetup commands correctly at least... (In reply to comment #4) > The updated function get_new_dm_volumes tries to create a associative array > "dmsetup_cmds" where the keys are volnames:, and values are the finished > dmsetup command. The array building cannot take place in a subshell which > are done in the original script (line 29&30) because then array variable > would not be available in the for loop afterward (not the same process). > This can be solved by using process substitution as I have done in the > attached script, but OpenRC won't parse it, giving that error message I > pasted earlier... > > I don't know if my escaping in line 35 is correct, I haven't come so far > that I've been able to test it. But it seemingly puts together the dmsetup > commands correctly at least... We can't do an associative array, it needs to be compatible with POSIX sh. Bash-only features cannot be used. I guess it'll be the same with that process substitution technique? I'll try to rewrite it without fancyness. Created attachment 336228 [details]
new /etc/init.d/device-mapper, working
I managed to rewrite the init file making it POSIX compliant, I think - but it is a bit ugly - I had to make a new function, build_dmsetup_command, that takes volume name as an argument, and then builds the command from data from /etc/dmtab, making the algorithm complexity something like O(n^3). get_new_dm_volumes are adjusted to only return unique volume names, and no parameters (it still checks if the volume is already set up).
It has lots of greps and awks, so if you know how to clean it up, then feedback is appreciated! But as far as I have tested, it seems to work :)
Created attachment 336244 [details, diff]
new device-mapper init.d in patch form
Here's a patch for the new device-mapper init.d
A typical use case for linear device mapper setup, is if you want to mount dynamic Windows-created extended NTFS volume consisting of several dynamic LDM partitions. I came over a case where an NTFS volume consisted of a large /dev/sda2 extended with a small /dev/sda1-partition. To mount something like that in Linux, you first have to set up device mapper to append sda1 to sda2 - then it will mount just fine with ntfs3g. In my current setup, I use a local.d-script running dmsetup to combine a 1TB drive with a 3TB drive creating two virtual 2TB drives, and then use those in a raid consisting of other 2TB drives. With this new device-mapper init.d, I could set everything up the right way. Just thought I should post this FYI, to get some use cases where it is useful. Even if the algorithm has lousy complexity, I don't think it is that easy to optimize away those recursive grep calls. Maybe if you store the dmtab output in a big variable with another IFS so you can have a multi-line variable, so you don't need those grep-calls parsing /etc/dmtab several times - but I don't know if the environment OpenRC needs to run on has a max size on how big environment variables can be. InCVS 2.02.105-r2 |