Score:21

Birth time of files are missing if file is created in a logical volume with size less than 512 MB

us flag

I have a volume group in my system, created with single physical volume.

I'm creating two logical volumes - one with size 100M and one with size 512M.

Any file created on LV with 100M size does not display birth-time attribute. LV with size 512M does not have this issue.

Any clue on why is this so?

Physical volume and volume group:

# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda4
  VG Name               VG_System
  PV Size               400.00 GiB / not usable 4.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              102399
  Free PE               38099
  Allocated PE          64300
  PV UUID               Awnq0n-24v1-Z53P-MC09-3Fvv-dc0r-6QvAyX


# vgdisplay VG_System
  --- Volume group ---
  VG Name               VG_System
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  25
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                24
  Open LV               22
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <400.00 GiB
  PE Size               4.00 MiB
  Total PE              102399
  Alloc PE / Size       64300 / 251.17 GiB
  Free  PE / Size       38099 / 148.82 GiB
  VG UUID               Zg53rH-kuCI-dWKa-Uo3H-Mr2i-G2As-Wflm0d

First LV:

# lvcreate --stripes 1 -n testing -L 100M VG_System
  Logical volume "testing" created.

# mkfs.ext4 /dev/VG_System/testing
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: ac9c1782-7770-4031-bad8-9b76f7577467
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


# blkid /dev/VG_System/testing
/dev/VG_System/testing: UUID="ac9c1782-7770-4031-bad8-9b76f7577467" BLOCK_SIZE="1024" TYPE="ext4"

# mount /dev/VG_System/testing /mnt/test
# mount | grep test
/dev/mapper/VG_System-testing on /mnt/test type ext4 (rw,relatime,stripe=4)

# touch /mnt/test/a
# stat /mnt/test/a
  File: /mnt/test/a
  Size: 0               Blocks: 0          IO Block: 1024   regular empty file
Device: 252,23  Inode: 12          Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-04-13 22:13:43.000000000 +0530
Modify: 2023-04-13 22:13:43.000000000 +0530
Change: 2023-04-13 22:13:43.000000000 +0530
 Birth: -

Here the Birth field is empty.

Second LV:

# lvcreate  -n testing2 -L 512M VG_System
  Logical volume "testing2" created.

# mkfs.ext4 /dev/VG_System/testing2
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 131072 4k blocks and 32768 inodes
Filesystem UUID: 0b5e24a9-cdf1-4749-9089-bf0cf1495185
Superblock backups stored on blocks:
        32768, 98304

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


# blkid /dev/VG_System/testing2
/dev/VG_System/testing2: UUID="0b5e24a9-cdf1-4749-9089-bf0cf1495185" BLOCK_SIZE="4096" TYPE="ext4"

# mount /dev/VG_System/testing2 /mnt/test2
# mount | grep test
/dev/mapper/VG_System-testing2 on /mnt/test2 type ext4 (rw,relatime)

# touch /mnt/test2/a
# stat /mnt/test2/a
  File: /mnt/test2/a
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 252,24  Inode: 12          Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-04-13 22:19:01.873047858 +0530
Modify: 2023-04-13 22:19:01.873047858 +0530
Change: 2023-04-13 22:19:01.873047858 +0530
 Birth: 2023-04-13 22:19:01.873047858 +0530

Note sure if it is relevant, but the mount options of first LV has stripe=4, where as second one does not have this. Other than this, both LVs are similar.

# lvdisplay VG_System/testing
  --- Logical volume ---
  LV Path                /dev/VG_System/testing
  LV Name                testing
  VG Name                VG_System
  LV UUID                n19sRr-SqHW-znjI-0fEW-MkQX-JRUn-MTmZHF
  LV Write Access        read/write
  LV Creation host, time controller, 2023-04-13 22:12:45 +0530
  LV Status              available
  # open                 0
  LV Size                100.00 MiB
  Current LE             25
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:23


# lvdisplay VG_System/testing2
  --- Logical volume ---
  LV Path                /dev/VG_System/testing2
  LV Name                testing2
  VG Name                VG_System
  LV UUID                94oJKP-r2Ob-ReHr-sDSO-t3HY-isJB-ZtEPsq
  LV Write Access        read/write
  LV Creation host, time controller, 2023-04-13 22:18:01 +0530
  LV Status              available
  # open                 1
  LV Size                512.00 MiB
  Current LE             128
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:24

Score:36
cn flag

It is not Issue with LVM. It is Issue with Ext4.

When the filesystem size is less than 512 MB , Ext4 uses Default Inode Size = 128 Bytes , which is not enough to store the "extended metadata".

When the filesystem size is more than 512 MB , Ext4 uses Default Inode Size = 256 Bytes , which is enough to store the "extended metadata" including "Birth time" @ offset 0x90 & offset 0x94.

More Details :
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Table

You can try this :

mkfs.ext4 -I 256 /dev/VG_System/testing  

This will force Inode Size = 256 on the Smaller filesystem.

More Details :
https://manpages.debian.org/bullseye/e2fsprogs/mke2fs.8.en.html

RonJohn avatar
id flag
@m.divya.mohan of course now there are 1/2 as many inodes on the 100MB volume. That could become a problem.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.