Skip to content

Conversation

@constrictor
Copy link

The idea is to use LDM protective partition block devices for dm calls instead of the whole disk block device.
This allows scenarios like booting Linux from LDM, when a separate protective partition is created exactly over the rootfs LDM partition, which allows mounting it directly, i.e. without ldmtool. Originally, it then prevents using ldmtool after such direct mount. This change fixes that.

@constrictor
Copy link
Author

I forgot to say: this change works on my system, which consists of 2 LDM disks in one group; one of the disks also contains rootfs made as a separate LDM protective partition; the other disk contains Windows that also made its disk C: a separate protective partition. The group contains both single and mirrored LDM volumes. The rootfs partition is mounted usually, i.e. not via ldmtool.

Before this change, calling "ldmtool create all" was only creating partitions that resize on the second disk and was failing for all partitions on the first disk (that contains mounted rootfs).

After this change, all seems to work as intended: calling "ldmtool create all" creates all volumes on both disks except for the rootfs volume (because rootfs is already mounted, so it's not available).

The idea is to use LDM protective partition block devices for dm calls
instead of the whole disk block device.
This allows scenarios like booting Linux from LDM, when a separate
protective partition is created exactly over the rootfs LDM partition,
which allows mounting it directly, i.e. without ldmtool. Originally,
it then prevents using ldmtool after such direct mount. This change
fixes that.
@rwmjones
Copy link
Collaborator

rwmjones commented May 2, 2025

To set expectations here, I'm not qualified to review or push this change.

@rwmjones rwmjones removed their request for review May 2, 2025 11:22
@constrictor
Copy link
Author

@rwmjones, who is then? You seem to be the only person pushing things to master over the recent years.

@rwmjones
Copy link
Collaborator

rwmjones commented May 2, 2025

We don't have any active maintainer at the moment. I'm only pushing simple fixes.

@constrictor
Copy link
Author

constrictor commented May 2, 2025

That sucks.

LDM is the only cross-platform RAID option that doesn't rely on any specific hardware. Intel fakeRAID (available via dmraid tool) would have been the best if not it's dependence on Intel. I use AMD and AMD fake RAID sucks on Windows and is dead on Linux. I need cross-platform RAID 1, so I'm here.

Here's my overview of this project:

  • It kinda works for simple cases, allowing users to mount and use LDM partitions that are not RAID1/RAID5.
  • There's a ton of problems when trying to use that seriously:
  1. It doesn't support booting from LDM disk. Which this patch is fixing, actually.
  2. It tries to map LDM when metadata is in unsafe state, i.e. there's incomplete LDM transaction. The minimal safe behavior would be to refuse to create partitions in such case. That's Throw an error and avoid working with disks that are in the middle of LDM transaction. #28.
  3. For RAIDs, it doesn't detect if RAID is in sync or if it needs repair (for example, because of simple PC power cycle). Mounting that is unsafe, especially since Windows will try to repair the volume later - after Linux does own changes. It can just damage file system if Linux takes one drive as master and Windows then repairs part of data from another.
  4. Of course, it doesn't support the repair itself. Which would involve modifying the LDM metadata, as it seems to have at least some progress information here. Modifying metadata is a tricky thing because it's transactional - but doable.
  • And there are some problems trying to extend the ldmtool:
  1. JSON output is stupid. This tool is used by real users. Any such output needs to be an option, not the default and the only output. This can't be fixed in a compatible way.
  2. Mixing error output and JSON is even worse. Yes, they go to different streams (stdout/stderr), but it's just a mix of JSON for some automated use and plain text for users.
  3. Command line parameters are weird. No flags, only words. Badly documented words.
  4. The split between libldm and ldmtool is artificial - can't write any other app without touching libldm. libldm does unrelated things like calling devmapper.
  5. (weak point, but still) Well, this tool could have been twice as small and much more readable if it was written in some C++. Or maybe Rust?

But this project is there and it's included into distributions. I don't want to go NIH and write my own thing, so I arrived with patches. I was interested in getting it working.

But it looks like I'll be forced to write my own thing... it's just sad.

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

Successfully merging this pull request may close these issues.

2 participants