The drive that my /home folder lives on is showing signs of failing, and I'm trying to migrate to a new drive.  I purchased a 4TB SSD, formatted it with ext4, mounted it as an external drive with a USB/SATA connector, and rsync’ed my /home folder over. So far, so good. But when I swapped it in place of the failing drive and rebooted, my OS reported:

unable to mount local folders
structure needs cleaning

That sounds like a corrupt file system, but fsck reported no errors. Maybe the new hardware is faulty, but I ran badblocks on it, and it also came back with no errors. I formatted it again and tried again, and came up with the same error. Weirdly, if I log in as root and manually mount the new /home drive, it mounts okay, and seems to accept read/writes. However, dmesg did show some errors for /dev/sdb (that's the /home drive on this system). I've copied them below, although I'm fluent enough myself to parse them. Any ideas? For context I'm running Gentoo Linux.

[    0.914006] sd 6:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
[    0.914052] sd 6:0:0:0: [sdb] Write Protect is off
[    0.914074] sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    0.914117] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    0.914224] sd 6:0:0:0: [sdb] Preferred minimum I/O size 512 bytes
[    0.915929]  sdb: sdb1
[    0.916093] sd 6:0:0:0: [sdb] Attached SCSI disk
[    5.012731] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[    5.012740] sd 6:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current] 
[    5.012747] sd 6:0:0:0: [sdb] tag#0 Add. Sense: Unaligned write command
[    5.012753] sd 6:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 08 10 00 00 00 08 00 00
[    5.012757] I/O error, dev sdb, sector 2064 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[    5.012786] sd 6:0:0:0: [sdb] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[    5.012792] sd 6:0:0:0: [sdb] tag#1 Sense Key : Illegal Request [current] 
[    5.012797] sd 6:0:0:0: [sdb] tag#1 Add. Sense: Unaligned write command
[    5.012802] sd 6:0:0:0: [sdb] tag#1 CDB: Read(16) 88 00 00 00 00 00 00 00 08 18 00 00 00 08 00 00
[    5.012805] I/O error, dev sdb, sector 2072 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[    5.012817] sd 6:0:0:0: [sdb] tag#31 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
[    5.012822] sd 6:0:0:0: [sdb] tag#31 Sense Key : Illegal Request [current] 
[    5.012827] sd 6:0:0:0: [sdb] tag#31 Add. Sense: Unaligned write command
[    5.012832] sd 6:0:0:0: [sdb] tag#31 CDB: Read(16) 88 00 00 00 00 00 00 00 08 08 00 00 00 08 00 00
[    5.012836] I/O error, dev sdb, sector 2056 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[   35.852468] sd 6:0:0:0: [sdb] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=30s
[   35.852476] sd 6:0:0:0: [sdb] tag#13 Sense Key : Illegal Request [current] 
[   35.852483] sd 6:0:0:0: [sdb] tag#13 Add. Sense: Unaligned write command
[   35.852490] sd 6:0:0:0: [sdb] tag#13 CDB: Read(16) 88 00 00 00 00 00 00 00 08 28 00 00 05 40 00 00
[   35.852494] I/O error, dev sdb, sector 2088 op 0x0:(READ) flags 0x84700 phys_seg 168 prio class 2
[   35.852574] sd 6:0:0:0: [sdb] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=30s
[   35.852581] sd 6:0:0:0: [sdb] tag#14 Sense Key : Illegal Request [current] 
[   35.852586] sd 6:0:0:0: [sdb] tag#14 Add. Sense: Unaligned write command
[   35.852591] sd 6:0:0:0: [sdb] tag#14 CDB: Read(16) 88 00 00 00 00 00 00 00 0d 68 00 00 05 40 00 00
[   35.852595] I/O error, dev sdb, sector 3432 op 0x0:(READ) flags 0x84700 phys_seg 168 prio class 2
[   35.852672] sd 6:0:0:0: [sdb] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=30s
[   35.852677] sd 6:0:0:0: [sdb] tag#15 Sense Key : Illegal Request [current] 
[   35.852682] sd 6:0:0:0: [sdb] tag#15 Add. Sense: Unaligned write command
[   35.852687] sd 6:0:0:0: [sdb] tag#15 CDB: Read(16) 88 00 00 00 00 00 00 00 12 a8 00 00 03 f0 00 00
[   35.852690] I/O error, dev sdb, sector 4776 op 0x0:(READ) flags 0x80700 phys_seg 126 prio class 2
[   36.858014] EXT4-fs (sdb1): ext4_check_descriptors: Checksum for group 18880 failed (53845!=52774)
[   36.858017] EXT4-fs (sdb1): group descriptors corrupted!

One further experiment: I tried installing another drive into the bay, and it also wouldn't auto mount as /home.  I could not even mount it manually after logging in as root.  As far as I can tell, there's nothing wrong with this third drive, and I can mount it just fine via a USB/SATA adapter.  Both of the new drives are SSDs, while the old failing drive that still mounts is a hard disk. This SATA port is via a SATA/PCIE adapter, so I suppose the problem could be in the adapter.  In that case, though, it's weird that the old hard drive still works.

The OS is Ubuntu 17.10 and I've been trying to recover(undelete) with extundelete. (The File System is ext4.) This didn't work. So, I tried with extundelete /dev/mapper/ubuntu--vg-root --restore-file /home/chan/origol/routes/user.js And It worked. However, I got another problem. Loading filesystem metadata ... extundelete: Block bitmap checksum does not match bitmap when trying to examine filesystem I couldn't find any information about it. How can I solve this problem?

I have an old 16GB SD card that started giving I/O errors, known it's gone bad, I dumped all the content to an image file to see what I could restore, and the Disk manager alerted me that 16.1MB were unreadable and replaced with zero. To do some post-mortem autopsy, I ran badblocks -n /dev/sdx (read only analysis). After ~18 hours, it reported 309 blocks as bad. To do some other testing, I erased just the partition table (it was two partitions, FAT32 + ext4) and ran badblocks -w /dev/sdx (read/write analysis). To my surprise, this time it took <6 hours and reported no bad blocks. I ran the read only analysis once again and also reported very quickly no bad sector. How is that possible? I was under the impression that badblocks checks for _physical_ blocks damage, and that in a flash device, if a block is reported as "bad", it's because the flash chip already ran out of space space to replace damaged blocks, but since removing the partition seemingly fixed the issues, it may look like they were some software corruption. After running badblocks these 3 times, I created a new partition table and a new partition, and filling it with data from /dev/zero reported no I/O error whatsoever. From what I can see, these are the possible explanations: * badblocks checks for FS bad blocks and my FS was corrupted, not the SD card flash itself * badblocks somewhat marked these blocks that are now automatically ignored by the hardware controller and/or the FS * the SD card noticed the bad memory area while badblocks was finding them and now replaced them with fresh ones. If so, why didn't it do when I got I/O errors from reading the files? Which one is the more likely?

I have this portable SSD drive that I am trying to format for use with my Raspberry Pi 3: https://www.amazon.com/gp/product/B00N0V4JG2 In the past I have used this exact product, but the 128GB version, formatted as FAT32 on my OSX machine, and the drive worked with no issues on the Pi. I'm using it store the Bitcoin blockchain. Now that the blockchain is too big I'm trying to replace the drive with a 512GB drive, and I am having no luck getting this thing to work! I first tried the OSX FAT32 format, but that didn't work. So I'm trying to format it with the Pi itself. Starting off with fdisk /dev/sda as sudo su with USB drive unmounted: /dev/sda1 2 1000215215 1000215214 477G b W95 FAT32 Then I go through the process of [d]elete, [n]ew, [w]rite: /dev/sda1 2048 1000215215 1000213168 477G 83 Linux but even after a partprobe AND a reboot, fdisk -l still reports no change: /dev/sda1 2 1000215215 1000215214 477G b W95 FAT32 ... am I doing anything wrong up to this point? I also went forward with mfks.ext4 /dev/sda1 and still don't see anything changing (I can post those logs too...) And when I run fsck it is a TOTAL BLOODBATH -- which is even more confusing! How can a freshly formatted, brand new file-system have so many errors? Stuff like this (selected examples out of hundreds): Inode 138789 has a extra size (30700) which is invalid Inode 138825 has a bad extended attribute block 17929510. Inode 138877 has compression flag set on filesystem without compression support. Inode 139153 has a extra size (6956) which is invalid Finally, when I attach the drive my OSX machine I can format it and use it and it works FINE. So I think the drive is not defective.

I'm facing the below filesystem error in SSD type disk with software raid configured machine. Is there any possible cause for this issue? Thank you for your help in advance. Kernel Version: 3.10.0-957.21.3.el7.x86_64 OS Version: CentOS 7.6.1810 EXT4-fs error (device md0): ext4_mb_generate_buddy:757: group 82800, block bitmap and bg descriptor inconsistent: 32768 vs 28640 free clusters EXT4-fs error (device md0): ext4_mb_generate_buddy:757: group 82816, block bitmap and bg descriptor inconsistent: 32768 vs 28640 free clusters EXT4-fs (md0): error count since last fsck: 70 EXT4-fs (md0): initial error at time 1617606033: ext4_mb_generate_buddy:757 EXT4-fs (md0): last error at time 1617606034: ext4_mb_generate_buddy:757

I only recently "discovered" the inline_data feature of ext4, although it seems to have been around for 10+ years. I ran a few statistics on various of my systems (desktop/notebook + server), specifically on the root filesystems, and found out that: - Around 5% of all files are < 60 bytes in size. The 60 byte threshold is relevant, because that's how much inline data you can fit in a standard 256 byte inode - Another ~20-25% of files are between 60 and 896 bytes in size. Again, the "magic number" 896 is how much you fit in a 1KB inode - Further 20% are in the 896-1920 byte range (you guess it - 1920 is what you fit into a 2KB inode) - That percentage is even more stunning for directories - 30-35% are below 60 bytes, and further 60% are below 1920 bytes. This means that with an inode size of 2048 bytes you can ***inline roughly half of all files and 95% of all directories on an average root filesystem***! This came as quite a shocker to me... Now, of course since inodes are preallocated and fixed for the lifetime of a filesystem, large inodes lead to a lot of "wasted" space, if you have a lot of them (i.e. a low inode_ratio setting). But then again, allocating a 4KB block for a 5 byte file is also a waste of space. And according to above statistic, half of all files on the filesystem and virtually all directories can't even fill half of a 4KB block, so that wasted space is not insignificant. The only difference between wasting that space in the inode table and in the data blocks is that you have one more level of indirection, plus potential for fragmentation, etc. The advantages I see in that setup are: - When the kernel loads an inode, it reads at least one page size (4KB) from disk, no matter if the inode is 128 bytes or 2KB, so you have zero overhead in terms of raw disk IO... - ... but you have the data preloaded as soon as you stat the file, no additional IO needed to read the contents - The kernel caches inodes more aggressively than data blocks, so inlined data is more likely to stay longer in cache - Inodes are stored in a fixed, contiguous region of the partition, so you can't ever have fragmentation there - Inlining is especially useful for directories, a) since such a high portion of them are small, and b) because you're very likely to need the contents of the directory, so having it preloaded makes a lot of sense What do you think about this setup? Am I missing something here, and are there some potential risks I don't see? I stress again that I'm talking about a root filesystem, hosting basically the operating system, config files, and some caches and logs. Obviously the picture would be quite different for a /home partition hosting user directories, and even more different for a fileserver, webserver, mailserver, etc. (I know there are a few threads describing some corner cases where inline_data does not play well with journaling, but those are 5+ years old, so I hope those issues have been sorted out.) **EDIT**: Since there are doubts expressed in the comments if directory inlining works - it does. I have already implemented the setup described here, and the machine I'm writing on right now actually is running on a root filesystem with 2KB inodes with inlining. Here's what /usr looks like in ls:

`
# ls -l /usr
total 160
drwxr-xr-x   2 root root 36864 Jul  1 00:35 bin
drwxr-xr-x   2 root root    60 Mar  4 13:20 games
drwxr-xr-x   4 root root  1920 Jun 16 21:32 include
drwxr-xr-x  64 root root  1920 Jun 25 21:16 lib
drwxr-xr-x   2 root root  1920 Jun  9 01:48 lib64
drwxr-xr-x  16 root root  4096 Jun 22 02:58 libexec
drwxr-xr-x  11 root root  1920 Jun  9 00:10 local
drwxr-xr-x   2 root root 12288 Jun 26 20:22 sbin
drwxr-xr-x 191 root root  4096 Jun 26 20:22 share
drwxr-xr-x   2 root root    60 Mar  4 13:20 src

` And if you dive even deeper and use debuge2fs to examine those directories, the ones having 60 or 1920 byte size have 0 allocated data blocks, while those having 4096 and more do have data blocks.

I'm trying to understand how ext4 does some things. I have a small ext4 partition with block size 1024 (not the default 4096). I create a directory there and delete lost+found, just to get it out of the way. When I stat the directory, it shows Size:1024 and Blocks:2 for "." (and ".."). So, that's 512*2, which makes sense. I then touch a file with 0 size, but a 250 character long name, as in "aaaa...aaa1". I touch "aaaa...aaa2" and "aaaa...aaa3". Stat still shows Size:1024 and Blocks:2. Then I touch "aaaa...aaa4" and stat jumps to Size: 3072 and Blocks: 6. I know the file name is in ext4_dir_entry_2, which is also stored in the data blocks. I guess I 1) don't understand the jump in Size and Blocks when creating the 4th files, and 2) I don't see the relation between file name and increase in size/block count.

# General overview I try to install the [Mobian](https://mobian-project.org/) OS on my Pinephone thought the [dd’s method](https://wiki.debian.org/InstallingDebianOn/PINE64/PinePhone#Method_3:_dd) as described in the official Debian documentation. Basically, I have to make a dd from an image to a partition in the SD card. # The problem But at each try, the partition is corrupted and unusable. # The process ### What I did As I said, I just follow the dd’s method of the documentation. So : 1. I formatted a partition located in /dev/sdb1 in my SD card with:

# mkfs.ext4 -F -O 64bit -L 'system' '/dev/sdb1'
mke2fs 1.47.0 (5-Feb-2023)
/dev/sdb1 contains a ext4 file system labelled 'system'
        last mounted on Wed Jun 25 18:44:21 2025
Creating filesystem with 28703488 4k blocks and 7176192 inodes
Filesystem UUID: e7df3b8b-a2fa-4cce-a833-5fd86456cad8
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872

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

2. Then, I get the image and unpack it:

$ wget https://images.mobian.org/pinephone/mobian-pinephone-phosh-12.0.img.gz 
$ unp mobian-pinephone-phosh-12.0.img.gz

3. So, I copied the image to the partition /dev/sdb1:

# dd bs=64k if=mobian-pinephone-phosh-12.0.img of=/dev/sdb1 status=progress 
5989138432 octets (6,0 GB, 5,6 GiB) copiés, 265 s, 22,6 MB/s
91552+1 enregistrements lus
91552+1 enregistrements écrits
6000000000 octets (6,0 GB, 5,6 GiB) copiés, 265,823 s, 22,6 MB/s

### What I got At this point, when the process reach it end, the partition appear as defective. 1. I check /dev/sdb1 with fsk.ext4 :

# fsck.ext4 /dev/sdb1
e2fsck 1.47.0 (5-Feb-2023)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 
 or
    e2fsck -b 32768 

Found a gpt partition table in /dev/sdb1

2. I inspected what happened with dmesg but found nothing special:

# dmesg -T
[mer. 25 juin 18:44:02 2025] sd 3:0:0:0: [sdb] 244285440 512-byte logical blocks: (125 GB/116 GiB)
[mer. 25 juin 18:44:02 2025] sd 3:0:0:0: [sdb] Write Protect is off
[mer. 25 juin 18:44:02 2025] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00
[mer. 25 juin 18:44:02 2025] sd 3:0:0:0: [sdb] No Caching mode page found
[mer. 25 juin 18:44:02 2025] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[mer. 25 juin 18:44:02 2025]  sdb: sdb1
[mer. 25 juin 18:44:02 2025] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[mer. 25 juin 18:44:02 2025] EXT4-fs (sdb1): recovery complete
[mer. 25 juin 18:44:02 2025] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Quota mode: none.
[mer. 25 juin 18:44:18 2025] EXT4-fs (sdb1): unmounting filesystem.
[mer. 25 juin 18:44:18 2025]  sdb: sdb1
[mer. 25 juin 18:44:18 2025] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Quota mode: none.
[mer. 25 juin 18:44:43 2025] EXT4-fs (sdb1): unmounting filesystem.

However, I tried the same process from another computer and get something more verbose with dmesg (in the this case mmcblk0 is the relevant partition):

[mar. juin 24 20:11:57 2025]  mmcblk0: p1 
[mar. juin 24 20:11:57 2025]  mmcblk0: p1 
[mar. juin 24 20:11:57 2025]  mmcblk0: p1 
[mar. juin 24 20:11:58 2025]  mmcblk0: p1 
[mar. juin 24 20:13:31 2025] mmc0: card 0001 removed
[mar. juin 24 20:13:33 2025] mmc0: cannot verify signal voltage switch
[mar. juin 24 20:13:33 2025] mmc0: new ultra high speed SDR104 SDXC card at address 0001
[mar. juin 24 20:13:33 2025] mmcblk0: mmc0:0001 SD128 116 GiB 
[mar. juin 24 20:13:33 2025]  mmcblk0: p1 
[mar. juin 24 20:13:38 2025] audit: type=1400 audit(1750788819.286:29): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/tmp/tumbler-X31LB82.png" pid=13008 comm="evince-thumbnai" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
[mar. juin 24 20:13:39 2025] audit: type=1400 audit(1750788819.666:30): apparmor="DENIED" operation="open" profile="/usr/bin/evince-thumbnailer" name="/tmp/tumbler-XD3SP82.png" pid=13013 comm="evince-thumbnai" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
[mar. juin 24 20:15:29 2025] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Quota mode: none.
[mar. juin 24 20:16:22 2025] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p5, blocknr = 1). There's a risk of filesystem corruption in case of system crash.
[mar. juin 24 20:16:26 2025] EXT4-fs error (device mmcblk0p5): ext4_map_blocks:607: inode #8: block 15237146: comm jbd2/mmcblk0p5-: lblock 26 mapped to illegal pblock 15237146 (length 1)
[mar. juin 24 20:16:26 2025] jbd2_journal_bmap: journal block not found at offset 26 on mmcblk0p5-8
[mar. juin 24 20:16:26 2025] Aborting journal on device mmcblk0p5-8.
[mar. juin 24 20:16:26 2025] EXT4-fs error (device mmcblk0p5): ext4_journal_check_start:83: comm ext4lazyinit: Detected aborted journal
[mar. juin 24 20:16:27 2025] EXT4-fs (mmcblk0p5): Remounting filesystem read-only
[mar. juin 24 20:23:19 2025] EXT4-fs (mmcblk0p5): unmounting filesystem.
[mar. juin 24 20:23:42 2025]  mmcblk0: p1 
[mar. juin 24 20:23:42 2025]  mmcblk0: p1 
[mar. juin 24 20:23:42 2025]  mmcblk0: p1 
[mar. juin 24 20:23:43 2025]  mmcblk0:
[mar. juin 24 20:23:43 2025]  mmcblk0:
[mar. juin 24 20:23:43 2025]  mmcblk0: p1
[mar. juin 24 20:23:43 2025]  mmcblk0: p1

# The question Obviously, I just ask what happened, why it doesn’t work? And how to fix it and install Mobian on this SD card?

If I try mounting the ext4 file system of /dev/mmcblk0p2 into the blank directories I just created: /SD and also /mnt/SD, then the command line answers with: sudo mount /dev/mmcblk0p2 /SD mount: mount /dev/mmcblk0p2 on /SD failed: File exists If I try out a non-existent directory such as /thispathdoesNotExist mount: mount point /thispathdoesNotExist does not exist Unmount? umount: /dev/mmcblk0p2: not mounted and: umount: /dev/mmcblk0: not mounted Is that not contradictive? **What does cause that problem, and how do I solve it?**

I had a dual-boot setup on my laptop, with the Windows partition first, then Linux. I decided to delete Windows, so I removed its partition and expanded the Linux partition into its space using GParted. e2image then moved all filesystem data back, beginning at the new start of the partition, and leaving the new empty space at the end. On an SSD (so no performance issues caused by fragmentation), is it really necessary to copy everything? I understand that some parts of the filesystem need to be in particular places (although I don't really understand how the filesystem is structured), but it doesn't seem like the file data itself would have this issue. If it is needed, why? If not, is there a way to disable it (either in GParted or manually with e2image) for faster repartitioning?

I was reading about Linux 5.2 patch note released at last year, I noticed that they started to [optional support for case-insensitive names in ext4 file system](https://kernelnewbies.org/Linux_5.2#Optional_support_for_case-insensitive_names_in_ext4) . So... what I am wondering is the reason why the case-insensitive option (including casefold and normalization) was needed in the kernel. I could find out [another article](https://www.collabora.com/news-and-blog/blog/2020/08/27/using-the-linux-kernel-case-insensitive-feature-in-ext4/) written by Krisman who wrote the kernel code for supporting case-folding file system, but case-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systems does not reach my heart and I cannot understand how the process of normalization and casefolding allow us to optimize our disk storage. I appreciate so much for your help!

On our RHEL 7.9 systems, we have noticed some strange behavior. Each machine has 4 disks, each with an 8TB capacity, but we are only using about 1.9TB on a partition. What doesn’t make sense is that the Use% value appears incorrect. As shown below, the usage of /data/sde is reported as 15%, but the actual used space is only 267MB, while the /dev/sdd1 partition size is 1.9TB. Filesystem Size Used Avail Use% Mounted on /dev/sdd1 1.9G 267M 1.6G 15% /data/sde Could this be related to how the partition was created, or is there something else causing this discrepancy? df -h Filesystem Size Used Avail Use% Mounted on /dev/sdg1 1.9G 5.7M 1.8G 1% /data/sdh /dev/sdf1 1.9G 5.7M 1.8G 1% /data/sdg /dev/sdb1 1.9G 44M 1.8G 3% /data/sdc /dev/sdd1 1.9G 267M 1.6G 15% /data/sde

I have a backup that was copied from Linux (ext4) to an exFAT filesystem. File and directory names that end with a period are inaccessible. I can (partly) list them, but ls behaves strangely. It prints errors like ls: cannot access '….': No such file or directory, and then prints the file name (with final period included), but reports -????????? for the permissions and ? for user, group, etc. I also can't move, rename, or delete any of the affected files. Using wildcards for the offending . does not work. This isn't a permissions issue. It might be a filesystem corruption issue, but if it is, it is a systematic one caused by rsync'ing a directory from an ext4 to exFAT filesystem, and affects *all* files and directories whose name ends in .. The command sudo fsck.exfat -v -p /dev/sd** reports volume clean. #### System info This is a Ubuntu Studio Ubuntu 22.04.1 LTS machine running the 6.2.0-1018-lowlatency kernel. The exFAT is an external USB drive (WD MyBook). I am mounting it via the system default mount option via the disks graphical user utility. The output of cat /proc/filesystems includes exfat, indicating kernel support; exfat-fuse is not installed, so it is probably not mounting via fuse. #### My questions: 1. What is going on here? 2. Do these files really exist, or are they ghosts (failed to copy to exFAT for *reasons*)? 3. Can I recover this? I'd like to rename all affected nodes by removing the trailing period.

I'm trying to recover an accidentally removed directory (/home/garid/.gnupg) with ext4magic. However, It outputs following error:

$ ext4magic /dev/nvme0n1p3  -f /home/garid/.gnupg/  -a $(date -d -5days +%s)
/dev/nvme0n1p3 Error 13 while opening filesystem
ext4magic : EXIT_SUCCESS

I'm not sure what I'm doing wrong. What is Error 13? And How can I make it work? --------------------------------------- My distro is Archlinux. My Partition table:

nvme0n1     259:0    0 476.9G  0 disk
├─nvme0n1p1 259:1    0     1G  0 part /efi
├─nvme0n1p2 259:2    0    32G  0 part [SWAP]
└─nvme0n1p3 259:3    0 443.9G  0 part /

--------------------- As suggested in below, running as root outputs below:

$ sudo ext4magic /dev/nvme0n1p3  -f /home/garid/.gnupg/  -a $(date -d -5days +%s)
[sudo] password for garid:
Filesystem in use: /dev/nvme0n1p3

Using  internal Journal at Inode 8
Activ Time after  : Sun Feb 26 20:15:57 2023
Activ Time before : Fri Mar  3 20:15:58 2023
zsh: segmentation fault  sudo ext4magic /dev/nvme0n1p3 -f /home/garid/.gnupg/ -a $(date -d -5days +%s)

This comes from a long story of trying to recovering a TrueCrypt volume from a hardware failure (thanks, WD). I ended up with an unencrypted 3TB image that had the files that I want to recover. Unfortunately, after using testdisk and extundelete, I guessed the directory entry that leads to the descriptors (of the additional directories) that I want to recover has been overwritten. However, I think that its subdirectories may have their entries still intact. I would like to know how can I search throughout the disk image for directory entries in unallocated blocks, in order to recover their files (with their proper names, which would be much better than using foremost, photorec and the like). I know that extundelete with a default --recover-all doesn't look further than the tree that spawns from the root directory. Okay, what if one of the branches is broken but I know that the subfolders entries are somewhere? Just in case I didn't express myself clearly, imagine that the entry lost is [root]/information. The root directory has the 'information' entry, but it points to overwritten data. Its directory entry is gone, but I want to scan for its subdirectories, [root]/information/personal, and [root]/information/business, and so on. (the name of those subdirectories was in the 'information' entry- I don't care about that name but their whole structure)

I'm wondering how terrible an idea the following is or is not... I want to share an ext4 fs between WSL2 and linux using a fixed-size .vhdx image created in windows (residing on NTFS partition). Mounting this in WSL is straightforward, but the issue I am trying to avoid is a bunch of FUSE or NBD overhead accessing the drive in native linux. No problems mounting the ntfs (mounted as ntfs3) partition, but to get to my question: is there any reason it is a bad idea to directly mount the ext4 partition that lives in the .vhdx file? I.E: mount -o offset=5MiB /mnt//ext4.vhdx It seems to work fine... for now.

System: Ubuntu 20.04 on WSL2 (Windows Subsystem for Linux) I can launch ext4 image using 'runqemu' tool if I build the image using yocto. But I have not built the image locally, I have installed qemu. If I try to launch using this command qemu-system-x86_64 -drive format=raw,file=core-image-qemux86-64.ext4 it gives me this error > Unable to init server: Could not connect: Connection refused WARNING: Image format was not specified for 'core-image-qemux86-64.ext4' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. qemu-system-x86_64: ext4: drive with bus=0, unit=0 (index=0) exists Would be great if anybody could help, thanks!

I am working on a ext4 file-system tool that aims to delete files such that they are not recoverable later on. My goal is to clear the inode metadata of a deleted file, but despite my efforts, the changes I make to the inode metadata are not reflecting when I inspect the inode later using stat. Here's the process I follow to modify the inode: 1. Fetch the inode using ext2fs_read_inode. 2. Modify the inode metadata by setting values like i_mode, i_links_count, etc., to zero or NULL. 3. Write the modified inode back to the filesystem using ext2fs_write_inode.

void clear_inode_metadata(ext2_filsys &fs, ext2_ino_t inode_num)
{
    ext2_inode inode;
    ext2fs_read_inode(fs, inode_num, &inode);

    inode.i_mode = 0;                        
    inode.i_links_count = 0;       
    inode.i_size = 0;            
    inode.i_size_high = 0;          
    inode.i_blocks = 0;          
    memset(inode.i_block, 0, sizeof(inode.i_block)); 

    ext2fs_write_inode(fs, inode_num, &inode);  // Write the cleared inode back to disk
}


void delete_file(const string &path, ext2_filsys &fs, const string &device)
{
    ext2_ino_t inode_num = fetch_file(path, fs, device);
    if (inode_num != 0)
    {
        overwrite_blocks(fs, device, path); // traverses extents and writes random data
        clear_inode_metadata(fs, inode_num);
    }

}

The inode metadata stays the same even after invoking clear_inode_metadata(). Also I have a file recovery module that uses a disk snapshot to recover files and to my surprise it is able to recover the file even after I overwrite the file using overwrite_blocks(). The snapshot stores extents used by an inode and the total size of the file. My questions: 1. Why aren't the changes to the inode metadata reflecting after calling ext2fs_write_inode? 2. Why is the file recovery tool still able to recover the file after I overwrite its blocks?

My problem is to *decode* the output of the command file -s /dev/sdX on my system (where /dev/sdX is the device file associated to a USB key). Below I'll show the output of the command file -s /dev/sdX where the device file /dev/sda1 is a partition formatted with a FAT32 filesystem, while the device /dev/sdb is a partition formatted with a NTFS filesystem. ### Output of file command for a FAT32 filesystem ### In the case of the FAT32 filesystem the output of the file command is:

> file -s /dev/sda1
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 31, hidden sectors 2048, sectors 1966080 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1920, reserved 0x1, serial number 0x4ba3ff5b, unlabeled

In the output is present the information , FAT (32 bit), sectors/FAT 1920, which could be enough to say that the filesystem type is FAT32, but in the next paragraph I'll show that the string FAT is also present in the output of the file command in the case of an NTFS filesystem. ### Output of file command for a NTFS filesystem ### In the case of a NTFS filesystem the output of the file command is:

> file -s /dev/sdb 
/dev/sdb: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, dos  file -s /dev/sdf
/dev/sdf: DOS/MBR boot sector

In this case exfat is not present in the output. ### Output of file for ext4 ###

file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=38bc3d5b-381e-4f19-8640-c77d9483882b (needs journal recovery) (extents) (64bit) (large files) (huge files)

In this case is present the info ext4 filesystem data,. In these 4 examples (FAT32, NTFS, EXFAT, EXT4) the output of the file command appears very different for different filesystem types, so it is difficult to find a simple rule to decide the filesystem type by this output. ___ **EDIT** To clarify why I'm trying to use the file command *to get information about the filesystem type of a USB*, please read [this post](https://unix.stackexchange.com/questions/794029/how-to-find-the-filesystem-type-of-the-partition-of-an-usb-before-mount-it) .

I am trying out different GNU/Linux distributions and I have several partitions on my disk, namely: /dev/sdc1 - primary, 83, ext4 /dev/sdc2 - primary, 83, ext4 /dev/sdc3 - primary, 82, swap /dev/sdc4 - extended /dev/sdc5 - logical, 83, ext4 /dev/sdc6 - logical, 83, empty /dev/sdc7 - logical, 83, empty /dev/sdc8 - logical, 83, empty /dev/sdc9 - logical, 83, empty /dev/sdc10 - logical, 83, ext4 I have installed Void Linux on /dev/sdc1 and Arch Linux on /dev/sdc5. Since I cannot boot Arch, I went to the grub shell to try and boot it manually. So I did the following: grub> set root=(hd2,msdos5) grub> ls ($root)/ error: unknown filesystem I do not understand this error. If I try grub> set root=(hd2,msdos1) grub> ls ($root)/ I get a listing of the root directory of /dev/sdc1. So I thought it might have to do with the logical partition and I tried: grub> set root=(hd2,msdos10) grub> ls ($root)/ which also works. So why doesn't grub see partition /dev/sdc5? What can be so special about it? All three partitions are formatted with an ext4 filesystem. Any clue?