2

Finding offset of a filesystem that resides directly on a partition is easy: check the partition start sector, multiply by sector size, done.

What if the filesystem lives inside LVM? I could scan the drive for its distinctive features like the magic number, UUID, etc., but I'm thinking of something that doesn't rely on matching by content.

Is there a generalized solution for all kinds of block devices? What about those that don't store data literally, like for example LUKS containers, dm-integrity and such? I don't think block devices form any kind of hierarchy, so I guess the answer is no?

Improve this question
5
  • 2
    This feels like a "why do you think you want to do that?" sort of question, honestly. What purpose is served by knowing a filesystem's physical location on media that isn't more easily served by accessing it through the LVM mapped devices? Especially when, with LVM, the rest of the filesystem is no longer remotely guaranteed to be found in contiguous blocks following that start position, like it is with traditional disk partitions. So even if you do know the physical start position, that info is useless.
    – FeRD
    Commented Mar 9 at 8:46
  • @FeRD Long story short, I have a system where I need to merge separate /boot into the root partition and extract it out of LVM (single lv) for reasons. I was wondering if I could carve it out of LVM by adjusting the partitions and to what extremes it could be taken. It's more of an experiment than actual necessity.
    – gronostaj
    Commented Mar 9 at 19:21
  • "Is there a generalized solution for all kinds of block devices?" -- this seems to be conflating at least two different things. Yes, technically, the bytes of your filesystem are stored on hardware presented to the system as one or more block devices, but it is a category error to think of that as the filesystem itself residing there. The filesystem itself resides on a logical volume, presented to the system as a different block device than any of the underlying physical drives.
    – John Bollinger
    Commented Mar 10 at 16:26
  • @JohnBollinger I'm not sure if I understand what you mean. The crux of the question is that the filesystem resides on a virtual block device (partition, lv, LUKS, …, possibly multiple layers) and I want to know the corresponding offset on a block device representing the actual physical hardware used to store that data.
    – gronostaj
    Commented Mar 10 at 19:53
  • I'm saying that the question is ill-formed. A filesystem stored on an LVM volume is not stored on the underlying physical devices in any useful sense. Yes, you can trace the bytes to physical hardware, but you do not thereby find the filesystem. It does not exist at that level.
    – John Bollinger
    Commented Mar 10 at 21:11

2 Answers 2

Reset to default
7

Anything relying on device mapper (including LVM) will show up as a device mapper table; you can see the tables set up on your system by running

dmsetup table

as root.

For a “simple” linear mapping, this would show something like

… 0 67108864 linear 8:0 2048

which says that there’s a single range of blocks mapped to device 8:0 (run lsblk to match that up with device nodes) starting at offset 2048.

As a general rule you can’t rely on just an offset, since an LVM LV can consist of multiple ranges on one or more PVs.

Improve this answer
2
  • 1
    And also, nothing says the ordering of blocks on the physical volume is the same as it is in the logical volume.
    – sina bala
    Commented Mar 9 at 0:13
  • @sinabala While that's true, the dmsetup table output does actually account for that, because disordered sections will be shown as separate entries. For example, my lv_users is defined in 5 groups of physical extents, spread across three PVs. dmsetup table shows it accordingly: vg00-lv_users: 0 1225064448 linear 8:4 160958464 / vg00-lv_users: 1225064448 209715200 linear 8:6 2048 / vg00-lv_users: 1434779648 83886080 linear 8:6 84428288 / vg00-lv_users: 1518665728 18153472 linear 8:6 389285888 / vg00-lv_users: 1536819200 202702848 linear 8:3 2048
    – FeRD
    Commented Mar 16 at 4:27
3

You can do this by looking at the actual device mapper tables as suggested by Stephen Kitt’s answer.

However, this information is borderline useless for any purpose other than replicating the device mapper tables, because there are exactly zero guarantees that any given logical volume consists of a contiguous region of blocks in the correct order on a single underlying device. Even without factoring in RAID setups, a single logical volume may span multiple physical volumes, and the individual physical extents are not even remotely guaranteed to be in the ‘correct’ order relative to each other based on the logical extent mapping, let alone adjacent to each other.

What this means is that you could have a logical volume where the first 16 MB are located at the very end of one physical volume, the next 30 GB are located on a different physical volume, the next 512 MB are located on the first physical volume but come before the first 16 MB, and the remaining space is located on a third physical volume. No matter what you are planning to do with your info about the ‘start’ of a filesystem, it’s pretty much guaranteed not to work in at least some cases.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .