Thanks for your comments and questions. I didn’t want to hijack the thread, just share similar experiences as the OP. In fact, the OP commented on my website where I posted about the ntfs3 issue.
First in reply to @megavolt: Reading my own post on my website I noticed that I made some mistakes in my replies above, thanks to @megavolt pointing out the dm-27.
Here is the corrected version of events, as described in my post and as far as I can recall now:
- I have a LVM volume called media-photo_raw that is formatted to NTFS and used entirely for backing up the picture files as they are imported by Adobe Lightroom (the “make a second copy to…” option on the LR import screen). The drive had been formatted to NTFS within the Windows VM. Of course, the files were copied while running the Windows VM.
- After I import the photos from memory card to my NVMe-based work drive called vmvg-workdrive, I go through them and delete those that I don’t want to keep. However, I do NOT touch the files on the media-photo_raw volume holding the backup on import. Obviously the media-photo_raw volume fills up rapidly. Once the photos on the vmvg-workdrive are processed, I move them to long-term storage on large HDDs (LVM volume in RAID1 that’s been formatted to NTFS by Windows 10).
- After each step I run a hash script that creates a list of files and the corresponding hashes, for each storage media/volume.
- Over time, the original backup files are not needed anymore, as I have multiple backups of the long-term storage drives. So I wrote a script that deletes photos on the media-photo_raw volume based on various criteria to free up space.
- When I ran the script the first time, it deleted around 27,000 files on media-photo_raw.
- About a month later, after importing more photos, I ran another script to update/add the hashes for the new files. This is where I got the “input/output errors”. I checked it by executing:
find . -type f -printf '%T+\t%s\t%i\t%p\n' > "$lof-new"
- At first I thought this was hardware failure of the HDD. I ran an extended SMART test and it came out clean. This is when I started to suspect the ntfs3 driver and did some Internet search to find that I am not alone.
(Sorry for the lengthy introduction, but it might be relevant.)
Now, below are the answers to your questions:
What backup script? I use Luckybackup (basically a front-end for rsync), which uses a bash script I wrote to mount the LVM-based NTFS partition. The command that mounts the file system is: mount -t ntfs3 -o "$rw_mode",iocharset=utf8,dmask=027,fmask=137,uid=$(id -u $user),gid=$(id -g $user),discard "$mount_dev" "$mount_path"
Important: I did not use any backup script on the media-photo_raw in question.
Here is the code snippet of the bash script that deleted the 27,000 files:
cnt=0
while read file; do
echo "Deleting $file"
rm "$file"
((cnt++))
done < "$lof-discard"
echo "$cnt files deleted from raw backup media"
echo "Removing $(find -depth -type d -empty | wc -l) empty folders"
find -depth -type d -empty -delete
echo "Removed empty folders";;
dm-27: This is the media-photo_raw LVM volume that was mounted by my script using the following mount option:
mount_op="-t ntfs3 -o ${rw},iocharset=utf8,dmask=027,fmask=137,uid=$user,gid=$group,discard"
mount ${mount_op} "${lvmount:-$lv_path}" "$mounton"
(About using photos: Totally agree!)
@linux-aarhus
NTFS - Only when challenged you provide extra information: I will gladly help where possible, but didn’t know if this here was the right place. To summarize my different NTFS use cases:
- LVM raw volume created by Linux, formatted by the Windows VM to NTFS.
- Native NTFS volume, typically a pre-formatted external HDD (like a WD Elements external drive).
Logical volume: I thought I made it clear that I use the Linux LVM. Microsoft doesn’t care much about open standards, so their proprietary version of LVM called “Storage Spaces” is a no-go for me. LVM stands for “Logical Volume Manager” and should be a familiar term to most Linux users.
As mentioned before, I use a mount script and a launcher to mount or unmount my NTFS volumes. The code that selects the right Windows partition to mount is here:
kpartx -av "$vm_path"
if [ -b "${vm_path}p1" ]; then
dev="$(lsblk -no NAME,SIZE ${vm_path}p? | sort -h -k 2 | awk '{ print $(NF-1) }')"
dev="$(echo $dev | awk '{ print $NF }')"
else
if [ -b "${vm_path}1" ]; then
dev="$(lsblk -no NAME,SIZE ${vm_path}? | sort -h -k 2 | awk '{ print $(NF-1) }')"
dev="$(echo $dev | awk '{ print $NF }')"
else
dev="$vm_volume"
fi
fi
As you can see, I use kpartx as device mapper (it supports even nested LVM volumes).
I think I have mentioned earlier the conflict of interest with Paragon Software: Of course I understand and appreciate the efforts that are going into the development of the ntfs3 driver. There must be a way to track that development, especially with regards to bugs.
Is my case of using NTFS on LVM an edge case? Perhaps, though I have no clue if the use of LVM or the device mapper kpartx has any bearing on the functionality of the ntfs3 driver. As I repeatedly mentioned, I used the ntfs-3g driver for around 12 years without an issue.
Could the large number of files I deleted be the issue? Perhaps.
I believe that at least one external drive was also affected. As explained before, these external drives don’t use LVM but were purchased pre-formatted with NTFS.
Important: The OP who started this thread does not use LVM! Unfortunately I didn’t screenshoot or copy the output of the chkdsk /F command under Windows, but I believe it mentioned “orphaned files”.
Does this answer the questions? If not I’m happy to add if and where I can.
(recently confirmed by a Team member)