Summary: | hal does not recognize LVM or MD volumes | ||
---|---|---|---|
Product: | hal | Reporter: | Martin Pitt <martin.pitt> |
Component: | hald | Assignee: | Danny Kukawka <danny.kukawka> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | high | CC: | andrew.james.barr, daniel.dumitrache, felipe.contreras, flomertens, irv, john, jreznik, lure, suse, tomwolfe |
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
URL: | https://launchpad.net/bugs/32814 | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Implementation of soft raid (md) that reads from /proc/mdstat
hal_mount_lvm.patch |
Description
Martin Pitt
2006-03-29 21:22:58 UTC
Yes this would be nice. Patches welcome. Btw, think we need kernel support for this. Btw, the patch should have a strlist of the hal device objects backing the volume.. just like we do for crypto.. Suggest following properties. bool volume.linux.is_lvm strlist volume.linux.lvm_backing_volumes = {hal_udi1, hal_udi2, ...} since you may stack LVM this is fun, you may have have to reference this property recursively to get the set of physical volumes... We probably shouldn't represent LVM volumes if they are not backed by a physical disk. Btw, one reason I also want this is to easily get to the physical drive for certain mount points.. Need this for tweaking disk standby via hdparm and sdparm when transitioning to battery for instance... Actually later kernels now export holders/ and slaves/ so we can use that. We should also have Setup() and Teardown() methods much like we do for LUKS. Let's also track the work needed for MD (multidisk, e.g. RAID) here Created attachment 9747 [details]
Implementation of soft raid (md) that reads from /proc/mdstat
This is an implementation of reading from /proc/mdstat from kde's ksysguard. It borrows heavily from the 'offical' mdadm program so logic wise it's up to date. It won't compile by itself, but the important parts of the two functions scanForArrays and getMdadmDetail. The other functions are just for ksysguardd. I've left them in just in case it helps anyone.
Added support for Linux RAID with this patch (check out the screenshots linked from the commit text!) http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=c53f3e46e53204bb1d1910b7fbbd81edaf61c29b Do we need more properties that these? I also (almost) avoid parsing /proc/mdstat since most of the stuff we need is in sysfs already. Anyway, device-mapper / LVM support shouldn't be too hard to add and it will even work with stacks containing both md and dm etc. I'll add that soon. Any update on devicemapper/LVM support? i did some works on it, and send my current patch to the mailling list for review : http://lists.freedesktop.org/archives/hal/2007-October/009815.html What is the current state of this bug or better feature request? I'm packaging some software (kio-sysinfo) which depends on volume info from Solid/HAL on Fedora 9. But default installation method of Fedora is to install to LVM. It seems that proposed patch was refused... Basic support of LVM would be very nice. yeah, that would be nice to have LVM/Raid supported by HAL. As anybody reviewed the patch at all? Created attachment 20657 [details] [review] hal_mount_lvm.patch ported patch from comment#8 to hal-0.5.11~rc2 HAL will detect the volumes. Would be nice to see this included in hal. Is anything wrong with the patch? just checked the patch from comment #11 and it works fine for me. any plans for merging it? What can I do to help get this fixed? In reply to questions about there being anything wrong with the patch, and being possibly pedantic, there do seem to be whitespace issues in the patch... (In reply to comment #15) > In reply to questions about there being anything wrong with the patch, and > being possibly pedantic, there do seem to be whitespace issues in the patch... You cannot be serious. Is that the reason why nobody has merged this in the past 7 months? If yes, it's a pretty lame reason, if no, then what's the point of fixing the whitespace issues if nobody is going to merge it? Since hal is obsolete now, and dk-disks has great support for MD, this is pretty much moot now. -> should this be "WONTFIX"? I'm not sure how, but at least in Fedora 11 LVM volumes are detected correctly :) Hi, I'm trying to describe a terrible situation: KDE4's dolphin can't trash files from Raid/lvm-volumes without breaking the specification. (http://www.ramendik.ru/docs/trashspec.html) That means it will move the filed over partition boundaries. Trashing big files (movies) is obviously is big problem (slowly and filling home partition) OK, there are already some bug reports out there and all are pointing to this bug. But the problem is that dolphin relies on hal, hal won't be fixed (but a patch is available!) and hal is obsolete. However, devicekit isn't used by dolphin. (I don't know, if this statement is correct. I just know that is doesn't work is it should.) (I installed openSUSE 11.2 Milestone 6, installed devicekit, add RAID1-Volume, /usr/bin/devkit-disks --mount /dev/md0 video, trash file ~/video/foobar, but it moves to home partion instead of ~/video/trash-$userid) My preferred solution is enable RAID/LVM support in HAL. if not, which steps are necessary to fix the user's problem? regards Dominik PS: bug reports: https://bugzilla.novell.com/show_bug.cgi?id=529790 "KDE4.3.0: throwing files into trash moves them over partition boundaries." https://bugs.kde.org/show_bug.cgi?id=178479 "trash io slave does not use $topdir/.Trash or $... " https://bugs.kde.org/show_bug.cgi?id=177023 "Dolphin doesn't fully implement freedesktop.org... " I'd like to clean my bug list a bit. This is certainly ooooold cruft. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.