I started copying (with rsync) a large chunk of data to that drive (26+ million files, tens of thousands of folders, about 2TB in total).
That much has been copied so far:
find /mnt/nvme0n1p1 -type f | wc -l
19868844
find /mnt/nvme0n1p1 -type d | wc -l
9327
After running for several hours, it refused to continue due to "no space
left on device".
I've confirmed the problem trying to save a text file there, same error.
df -hT /mnt/nvme0n1p1
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p1 fuseblk 3.7T 1.1T 2.6T 30% /mnt/nvme0n1p1
df -i /mnt/nvme0n1p1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/nvme0n1p1 2768000256 19888329 2748111927 1% /mnt/nvme0n1p1
Mount options of the destination as requested:
root@eagle:~# mount | grep /mnt/nvme0n1p1
/dev/nvme0n1p1 on /mnt/nvme0n1p1 type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
rsync -av /mnt/sdb1/data-mirror/ /mnt/nvme0n1p1/data-mirror/ --progress --delete
root@eagle:~# df -h /mnt/nvme0n1p1
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 3.7T 1.1T 2.6T 30% /mnt/nvme0n1p1
and this is the source:
root@eagle:~# df -hT /mnt/sdb1/
Filesystem Type Size Used Avail Use% Mounted on
/dev/sdb1 ext4 7.3T 6.0T 943G 87% /mnt/sdb1
Mount options of the destination as requested:
ntfs partition is reported via the "mount" command, among others.
So this is an NTFS file system that you're writing to? I think that's
got to be related to your problems somehow. Maybe you're exceeding
some limit in the Linux NTFS driver (single file size, total capacity,
who knows).
The command was:
rsync -av /mnt/sdb1/data-mirror/ /mnt/nvme0n1p1/data-mirror/ --progress --delete
After running for several hours, it refused to continue due to "no space
left on device".
I've confirmed the problem trying to save a text file there, same error.
What else could it be and how to fix it?
After running for several hours, it refused to continue due to "no space
left on device".
I've confirmed the problem trying to save a text file there, same error.
Hmm... I don't see anything amiss in the data you sent, so I'm afraid
I don't know what's going on. Have you tried to delete one of the files
you just wrote (just to see if other modifications still work,
rather than the system behaving as if it's read-only)?
Any message about your NVMe device (or its filesystem) in dmesg?
Finally, please show the mount options of whatever file system is
full. This means grepping something out of the output of "mount".
It can be difficult to get the right line sometimes.
Adam Weremczuk wrote:
The command was:
rsync -av /mnt/sdb1/data-mirror/ /mnt/nvme0n1p1/data-mirror/ --progress --delete
If you're running out of disk space, use option "--delete-before" instead of "--delete"
"FUSEBLK" is just how an NTFS partition is reported via the "mount" command, among others. This is how NTFS-3g operates. It is normal. Hence, as long as you have permission to mount and access the device, it's OK, and you shouldn't worry about anything.
My assumption is: this source file has over 1.7 TB size, and as your target disk has 3.7 TB size, and the target disk is already 1.1 TB full, it won't fit.
Best regards,
Klaus.
Good idea, Klaus!
It looks like Adam wants to copy a Windows system to another drive. Maybe he could delete hyberfile.sys, pagefile.sys and swapfile.sys before rsyncing.
These are not necessary and will be recreated at boot from Windows next time.
Just an idea....
Hans
Syslog reveals this:
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: No
space left on device
I need NTFS to connect it to a WS 2019 machine later.
I thought it would be easier than fiddling with WSL or pay for
something like: https://www.paragon-software.com/home/linuxfs-windows/
(which seems decent)
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: No space left on device
Jan 13 19:46:15 eagle ntfs-3g[4262]: message repeated 3154 times: [ No free mft record for $MFT: No space left on device]
All files copied were under 500 MB in size each, guaranteed.
No dmesg entries from around the copy failure time.
Syslog reveals this:
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: No
space left on device
Jan 13 19:46:06 eagle ntfs-3g[4262]: message repeated 40 times: [ No
free mft record for $MFT: No space left on device]
Jan 13 19:46:06 eagle smartd[988]: Device: /dev/sdb [SAT], SMART
Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 81 to 76
Jan 13 19:46:06 eagle smartd[988]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 64 to 65
Jan 13 19:46:06 eagle smartd[988]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 36 to 35
Jan 13 19:46:06 eagle smartd[988]: Device: /dev/sdb [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 81 to 76
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: No
space left on device
Jan 13 19:46:15 eagle ntfs-3g[4262]: message repeated 3154 times: [ No
free mft record for $MFT: No space left on device]
Is it some kind of NVMe temp garbage overhead?
Is it some kind of NVMe temp garbage overhead?
Possibly. I haven't been following the thread very attentively and have no particular expertise, but maybe you are running to an issue similar to
the one described in the link below where the garbage collection of the NVMe's internal index of space usage doesn't happen fast enough:
https://github.com/FOGProject/fogproject/issues/421#issuecomment-1507351213
From what I could find, the MFT (Master File Table) sounds similar toa table of inodes, and it should grow as needed, so it seems like "no
On Tue, Jan 14, 2025 at 15:25:02 +0000, Adam Weremczuk wrote:
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: No space left on device
Jan 13 19:46:15 eagle ntfs-3g[4262]: message repeated 3154 times: [ No free mft record for $MFT: No space left on device]
This is *absolutely* something to do with NTFS, so I don't know how much
help we'll be able to give.
On 14/01/2025 15:14, Hans wrote:
It looks like Adam wants to copy a Windows system to another drive. Maybe he >> could delete hyberfile.sys, pagefile.sys and swapfile.sys before rsyncing. >>
These are not necessary and will be recreated at boot from Windows next time.
Just an idea....
I need NTFS to connect it to a WS 2019 machine later.
I thought it would be easier than fiddling with WSL or pay for something like: https://www.paragon-software.com/home/linuxfs-windows/ (which seems decent)
I need NTFS to connect it to a WS 2019 machine later.
Am Dienstag, 14. Januar 2025, 16:25:02 CET schrieb Adam Weremczuk:
Syslog reveals this:
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: No
space left on device
--------------------
Hmm, MFT too small? A quick search showed me this (from a forum):
Note that Dell computers we received were all delivered with 50% MFT reserve. We use many
large files and reducing the MFT reserve to 12.5% saved these machines from being dog slow
when they ‘filled up’ quickly.
How much MFT space is needed? *My rule of thumb for estimating is ‘number of files times 4k
divided by total drive size’. The result is the percent of drive space needed for MFT. *As you
note, the actual requirement will vary… but you have to start some place!
Howsever, I suppose, others know better than me, like before, just an idea...
All files copied were under 500 MB in size each, guaranteed.
No dmesg entries from around the copy failure time.
Syslog reveals this:
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: No space left on device
On Tue, Jan 14, 2025 at 03:30:17PM +0000, Adam Weremczuk wrote:
I need NTFS to connect it to a WS 2019 machine later.
Have you considered exfat? Support for that on linux is much better than ntfs.
At the very least I'd format the drive as anything other than ntfs and
retry as suggested elsewhere to confirm that it actually works as
expected. (Storage fraud really is a thing, where people sell drives
that have less storage than reported, on the theory that most people
won't fill it up in time to get their money back.)
I'm giving exfat a shot and so far I'm impressed with 160 MB/s average >transfer rate (HDD -> NVMe).
That's significantly faster than before.
Partially because I'm using "rsync -avh --no-perms --no-group
--no-owner ..." this time.
On Tue, Jan 14, 2025 at 03:30:17PM +0000, Adam Weremczuk wrote:I have a box of those, bought as 4T's, are actually 64k sd cards with a
I need NTFS to connect it to a WS 2019 machine later.
Have you considered exfat? Support for that on linux is much better
than ntfs.
At the very least I'd format the drive as anything other than ntfs and
retry as suggested elsewhere to confirm that it actually works as
expected. (Storage fraud really is a thing, where people sell drives
that have less storage than reported, on the theory that most people
won't fill it up in time to get their money back.)
.
On 14/01/2025 17:02, Michael Stone wrote:
On Tue, Jan 14, 2025 at 03:30:17PM +0000, Adam Weremczuk wrote:I bought the drive from Amazon and everything looks very genuine.
I need NTFS to connect it to a WS 2019 machine later.... (Storage fraud really is a thing, where people sell drives
that have less storage than reported, on the theory that most people
won't fill it up in time to get their money back.)
Nvme tool reports:
$ sudo nvme list
Node SN Model Namespace
Usage Format FW Rev
--------------------- -------------------- ---------------------------------------- ---------
-------------------------- ---------------- -------- /dev/nvme0n1 S7DSNJ0X910743Z Samsung SSD 990 PRO with
Heatsink 4TB 1 1.19 TB / 4.00 TB 512 B + 0 B
4B2QJXD7
The firmware seems to be the latest version: https:// semiconductor.samsung.com/consumer-storage/support/tools/
I'm giving exfat a shot and so far I'm impressed with 160 MB/s average transfer rate (HDD -> NVMe).
That's significantly faster than before.
Partially because I'm using "rsync -avh --no-perms --no-group --no-
owner ..." this time.
I suggest that you unmount any filesystems on the SSD and then fill the SSD with random bytes using dd(1).
Hi David,
On Tue, Jan 14, 2025 at 07:28:28PM -0800, David Christensen wrote:
I suggest that you unmount any filesystems on the SSD and then fill the SSD >> with random bytes using dd(1).
If the purpose of this is to check that the full capacity of the NVMe is working, the f3 tool that is already packaged in Debian makes this job
much more straightforward.
But OP's problem is more likely to be some issue with the ntfs-3g driver
or the NTFS filesystem on the NVMe.
On Tue, Jan 14, 2025 at 06:13:44PM +0000, Adam Weremczuk wrote:
I'm giving exfat a shot and so far I'm impressed with 160 MB/s average transfer rate (HDD -> NVMe).
That's significantly faster than before.
Partially because I'm using "rsync -avh --no-perms --no-group --no-owner ..." this time.
fuse is slow in general and that applies to ntfs-3g. There's a kernel exfat module which will offer performance similar to any other native filesystem.
Probably better since disk controllers often use compression to
minimize writes and blocks written during a write cycle.
Reliably Erasing Data from Flash-Based Solid State Drives, <https://www.usenix.org/legacy/event/lisa11/tech/slides/wei.pdf>,
Practical Erase Suspension for Modern Low-latency SSDs, <https://www.usenix.org/system/files/atc19-kim-shine.pdf>, In-drive
SSD compression boosts performance and endurance, <https://blocksandfiles.com/2019/09/03/compression-inside-qlc-ssd-endurance/> and friends.
Probably better since disk controllers often use compression to
minimize writes and blocks written during a write cycle.
Probably better since disk controllers often use compression to minimize writes and blocks written during a write cycle.
Using a random stream during zeroization due to write compression has
been a security control for at least 15 years. This should be no
surprise to anyone nowadays.
Using compression to minimize writes is part of a write leveling
strategy to extend drive life. <https://www.google.com/search?q=what+is+disk+write+leveling>.
I have the following in ~/.bashrc for making that easier:
alias Mnt='mount | egrep -v "cgroup|rpc|ramfs|tmpfs|^sys|on /dev|on /proc|on /sys|on /var" | sort '
Jeffrey Walton (12025-01-15):
Using compression to minimize writes is part of a write leveling
strategy to extend drive life. <https://www.google.com/search?q=what+is+disk+write+leveling>.
So you say, and all you have to quote for it is a Google search result
page. This is how far I am willing to discuss this.
On Tue, Jan 14, 2025 at 03:26:17PM -0500, Michael Stone wrote:
On Tue, Jan 14, 2025 at 06:13:44PM +0000, Adam Weremczuk wrote:
I'm giving exfat a shot and so far I'm impressed with 160 MB/s average
transfer rate (HDD -> NVMe).
That's significantly faster than before.
Partially because I'm using "rsync -avh --no-perms --no-group --no-owner >> > ..." this time.
fuse is slow in general and that applies to ntfs-3g. There's a kernel exfat >> module which will offer performance similar to any other native filesystem.
[...]
See the other thread. The problem isn't speed or ntfs-3g.
It is most probably that the NTFS is running out of mft records [1], a >resource you set up when making the ntfs file system. Man mkntfs(8), option
On Wed, Jan 15, 2025 at 05:53:18AM +0100, [email protected] wrote:
It is most probably that the NTFS is running out of mft records, a
resource you set up when making the ntfs file system [...]
I'm skeptical of this and feel it's more likely an ntfs-3g issue, as it's
not normal for people to have to reformat ntfs volumes [...]
Felix Miata <[email protected]> writes:
I have the following in ~/.bashrc for making that easier:
alias Mnt='mount | egrep -v "cgroup|rpc|ramfs|tmpfs|^sys|on /dev|on /proc|on /sys|on /var" | sort '
mount | fgrep -vf <(awk '/^nodev/{print $2}' /proc/filesystems)
Urs Thuermann <[email protected]> writes:
mount | fgrep -vf <(awk '/^nodev/{print $2}' /proc/filesystems)
Thanks. It has the benefit of not showing autofs, for example. But how
to quote that for an alias?
Hi all,
An update on my struggle.
I followed the extfat path but I likely somehow make a noobish mistake
and a partition was not created...
Despite that, I was able to mount it an copy all the data across to it!
Now when I try to mount the NVMe on a different Ubuntu system (through USB adapter) I get:
$sudo mount /dev/sdb /mnt/sdb
mount: /mnt/sdb: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error.
Now when I try to mount the NVMe on a different Ubuntu system (through USB adapter) I get:
$sudo mount /dev/sdb /mnt/sdb
mount: /mnt/sdb: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error.
$sudo parted /dev/sdb
GNU Parted 3.4
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Realtek RTL9210B-CG (scsi)
Disk /dev/sdb: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
(parted)
You're trying to mount an entire disk, but that disk has an msdos
partition table with*no* partitions.
There are several problems here:
1) An msdos partition table only supports disks up to 2 TB and yours
is 4 TB.
2) You didn't create any partitions.
3) You didn't create an exfat file system, either on the raw device or
on a partition.
My advice would be:
1) Put a GPT partition table on the disk instead of msdos.
2) Create a single partition that spans all the usable space.
3) Create an exfat file system on that partition.
After that, you should be able to mount /dev/sdb1 wherever you like.
An alternative path would be:
1) Create an exfat file system on the raw device (/dev/sdb).
2) Mount /dev/sdb directly.
I don't think this is wise, simply because it may lead to surprises
in the future, when you forget that you've done it this way, or when
someone else tries to use this disk and expects it to have partitions. However, it*is* a choice that you could make.
Please see the attached illustrating that, no destructive steps taken yet.
On 20/01/2025 12:55, Adam Weremczuk wrote:
Gparted seems to recognise the fact that 53% of space has data written
to it. It also knows about the extfat system.
This morning, when I viewed the drive through gparted on a new machine
for the first time, it specifically complained about exfatprogs missing
and told me to install it.
I'm also wondering why a lack of partition wasn't reported in earlier stages and I managed to mount /dev/sdb instead of /dev/sdb1 and write to it?
There are fake 4TB drives in the market. Maybe you got one? There are some tools available for checking this (I believe, in Debian there is a tool called
"f3" or similar.
If there are no important data on the drive, you might reformat the drive to ext2/3/4 and then use "resize2fs" to corect the settings of your drive. In the
past I used to grow a partition with gparted, and gparted showed correctly, but df showed still the old size.
Resize2fs then did the trick and I got the correct size.
If you have Windows on an other computer, there are so,e windows based tools, which are made for testing the real capacity of your drive.
Additionally I got such a fake 4TB drive. Although the tools al showed "fake",
I could fill it with almost 4TB. Inside was of the case was an USB-stick and I
think, the capacity is made by software (shrinking files, double space whatver). However, this stick is (USB-3!) raaaaaaather slow!
Just some thoughts, maybe it helps.
Best
Hans
On 20/01/2025 20:37, Adam Weremczuk wrote:
sudo mount /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on
/dev/ nvme0n1, missing codepage or helper program, or other error.
Is it for the drive plugged directly into a M.2 slot or through a USB adapter? In the latter case you should mount something like /dev/sdb.
Notice that Dan suggested to explicitly specify filesystem type to mount
(-t exfat). Review drives you have connected
lsblk --fs -o +SIZE
I have tried a USB pendrive with exfat partition
file -s /dev/sdb1
/dev/sdb1: DOS/MBR boot sector
Perhaps it is due to "AA55h" signature in 510 and 511 bytes just like in
MBR partition table <https://learn.microsoft.com/en-gb/windows/win32/fileio/exfat-specification#3120-bootsignature-field>
So tools unaware of filesystem name in 3-10 bytes may be confused. Maybe
they do not expect a "superfloppy" and take MBR with no partitions
hypothesis first.
Yes, /dev/nvme0n1 comes from the onboard M2 socket (where the drive was populated with data) and /dev/sdb comes from USB adaptor used to connect
the same drive to a different Ubuntu desktop.
Output from the first (/dev/nvme0n1 on board) loadout.
$ sudo lsblk --fs -o +SIZE
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS SIZE loop0 squashfs 4.0 0 100% /snap/core20/2379 64M
loop1 squashfs 4.0 0 100% /snap/bare/5 4K
loop2 squashfs 4.0 0 100% /snap/core20/2434 63.7M
loop3 squashfs 4.0 0 100% /snap/core22/1663 73.9M
loop4 squashfs 4.0 0 100% /snap/core22/1722 73.9M
loop5 squashfs 4.0 0 100% /snap/gnome-3-38-2004/119 346.3M
loop6 squashfs 4.0 0 100% /snap/gnome-3-38-2004/143 349.7M
loop7 squashfs 4.0 0 100% /snap/gnome-42-2204/176 505.1M
loop8 squashfs 4.0 0 100% /snap/gtk-common-themes/1535 91.7M
loop9 squashfs 4.0 0 100% /snap/snap-store/1113 12.9M
loop10 squashfs 4.0 0 100% /snap/snap-store/1216 12.2M
loop11 squashfs 4.0 0 100% /snap/snapd/23258 44.3M
loop12 squashfs 4.0 0 100% /snap/snapd/23545 44.4M
loop13 squashfs 4.0 0 100% /snap/snapd-desktop-integration/247 564K
loop14 squashfs 4.0 0 100% /snap/snapd-desktop-integration/253 568K
sda 953.9G
├─sda1 vfat FAT32 D7C9-A88E 487.3M 5%
/boot/efi 512M └─sda2 ext4 1.0 7258149c-b137-4855-b4d8-44dfb426e1f9
208G 73% / 953.4G
sdb 7.3T
└─sdb1 ext4 1.0 ARCHIVE-1 8186b203-86ce-439c-a2e7-988e121ea53b
7.3T
nvme0n1 exfat 1.0 6786-F242
3.6T
There are other disks on board: 1TB sda (SSD) and 8TB sdb (HDD).
On the same system I get:
$ sudo file -s /dev/nvme0n1
/dev/nvme0n1: DOS/MBR boot sector
...and I'm pretty sure I initialised the drive with GPT partition table.
It would be enough to somehow mount it in the current loadout and copy
the data to another spare 2 TB SSD. That would save me 3 days spent
waiting for the data to be processed.
The drive was mounted there and everything worked up until a reboot.
So maybe there is a way to remount it?
On 20/01/2025 15:44, Max Nikulin wrote:
On 20/01/2025 20:37, Adam Weremczuk wrote:
sudo mount /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on
/dev/ nvme0n1, missing codepage or helper program, or other error.
Is it for the drive plugged directly into a M.2 slot or through a USB
adapter? In the latter case you should mount something like /dev/sdb.
Notice that Dan suggested to explicitly specify filesystem type to
mount (-t exfat). Review drives you have connected
lsblk --fs -o +SIZE
I have tried a USB pendrive with exfat partition
file -s /dev/sdb1
/dev/sdb1: DOS/MBR boot sector
Perhaps it is due to "AA55h" signature in 510 and 511 bytes just like
in MBR partition table
<https://learn.microsoft.com/en-gb/windows/win32/fileio/exfat-specification#3120-bootsignature-field>
So tools unaware of filesystem name in 3-10 bytes may be confused.
Maybe they do not expect a "superfloppy" and take MBR with no
partitions hypothesis first.
Also:
sudo mount -t exfat /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on /dev/nvme0n1, missing codepage or helper program, or other error.
makes no difference.
Also:
sudo mount -t exfat /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on /dev/nvme0n1, missing codepage or helper program, or other error.
makes no difference.
Am Montag, 20. Januar 2025, 17:15:40 CET schrieb Adam Weremczuk:
Try "chkdsk /F /R C:" in windows, this should help.
If you do not own a windows computer, then you can use any windows-live-cd for
that, like Falcon4, HirensBootCD or UBCD4Win.
Hans
Also:
sudo mount -t exfat /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on
/dev/nvme0n1, missing codepage or helper program, or other error.
makes no difference.
I'm unable to mount the disk in Windows without formatting to assigne a letter, so can't do "chkdsk ... C:"No, you do NOT have to mount the drive. Just boot windows into rescue mode and then got to the DOSshell and do chckdsk on the correct volume (C: , D: , F: whatever).
Windows just reports something that looks like two blank partitions,
both with 2TB of unallocated space.
Please see a screenshot attached to my message from about 4.5 hrs ago
showing that.
The system/loadout I'm using is not "live" but installed on sda (localJust "mount /dev/nvme0n1p3 /my_mountpoint" should work.
1TB SSD).
I've tried mounting the troublesome 4TB NVMe on 3 different systems already. I think it has more to do with a specific sequence of commands or a tool allowing me to access that (apparently) inaccessible data.
Any ideas, even risky ones, are welcome.
I have little to lose at this point.
On 20/01/2025 16:29, Hans wrote:
Am Montag, 20. Januar 2025, 17:15:40 CET schrieb Adam Weremczuk:
Try "chkdsk /F /R C:" in windows, this should help.
If you do not own a windows computer, then you can use any windows-live-cd for that, like Falcon4, HirensBootCD or UBCD4Win.
Hans
Also:
sudo mount -t exfat /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on
/dev/nvme0n1, missing codepage or helper program, or other error.
makes no difference.
I don't think it's fake but it's the lack of partition being the main
issue.
I've just reconnected it to the previous system and found this in history:
sudo mkfs.exfat /dev/nvme0n1
sudo mkdir /mnt/nvme0n1
sudo mount /dev/nvme0n1 /mnt/nvme0n1
I think the fact that it reported as nvme0n1 cofused me and made me
think it was a partition.
All of the above worked and I was using the drive for days.
I ran: rsync, ls, df, cd, rm, rmdir and other commands.
Everything felt perfectly normal.
Now I'm unable to remount it the same way:
sudo mount /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on /dev/ nvme0n1, missing codepage or helper program, or other error.
I think it's time to give up on the data and move on...
Also:
sudo mount -t exfat /dev/nvme0n1 /mnt/nvme0n1
mount: /mnt/nvme0n1: wrong fs type, bad option, bad superblock on /dev/ nvme0n1, missing codepage or helper program, or other error.
makes no difference.
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: NoHmm, MFT too small? A quick search showed me this (from a forum):
space left on device
Note that Dell computers we received were all delivered with 50% MFT
reserve. We use many large files and reducing the MFT reserve to
12.5% saved these machines from being dog slow when they ‘filled up’ quickly. How much MFT space is needed? *My rule of thumb for
estimating is ‘number of files times 4k divided by total drive
size’. The result is the percent of drive space needed for MFT. *As
you note, the actual requirement will vary… but you have to start
some place!
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: NoHmm, MFT too small? A quick search showed me this (from a forum):
space left on device
AFAIK the MFT is implemented as a "normal" file; it can grow as needed
like any other file.
So, as long as there's room on the disk, it should not be "too small"
(tho maybe ntfs-3g just fails to implement some growth options,
e.g. maybe it only supports a contiguous MFT?).
Note that Dell computers we received were all delivered with 50% MFT reserve. We use many large files and reducing the MFT reserve to
12.5% saved these machines from being dog slow when they ‘filled up’ quickly. How much MFT space is needed? *My rule of thumb for
estimating is ‘number of files times 4k divided by total drive
size’. The result is the percent of drive space needed for MFT. *As
you note, the actual requirement will vary… but you have to start
some place!
Note that this "reserve" is only a strategy to reduce the risk of
needing to use a fragmented MFT (https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/ntfs-reserves-space-for-mft):
Because of the importance of the MFT to NTFS and the possible impact
on performance if this file becomes highly fragmented, NTFS makes
a special effort to keep this file contiguous. NTFS reserves 12.5
percent of the volume for exclusive use of the MFT until and unless
the remainder of the volume is used up. Thus, space for files and
directories is not allocated from this MFT zone until all other
space is allocated first.
So the size of the "MFT reserve" can impact performance but should never cause a disk to appear full when it isn't.
Stefan
I love three letter acronyms ! So meaningful (of course, context helps)
I am going to guess with large capacity drives, and large SAN environments, Master File Table (MFT) management and scalability is critical ?
I am curious: Are you storing many small files? What is the size of the NTFS partition? What happens if the NTFS partition is resized to be much larger?
https://www.ibm.com/think/topics/managed-file-transfer
What is managed file transfer (MFT)?
Managed file transfer (MFT) is a technology platform that allows organizations to reliably exchange electronic data between systems and people, within and outside the enterprise, securely and in compliance with applicable regulations.
MFT is a more reliable and efficient means for secure data and file transfer, outpacing and outperforming applications such as file transfer protocol (FTP), hypertext transfer protocol (HTTP), secure file transfer protocol (SFTP) and other methods.
https://www.sciencedirect.com/topics/computer-science/master-file-table Master File Tableespecially valuable in forensic investigations as it allows investigators to retrieve information about deleted files, even though the file names may not always be preserved.
In subject area: Computer Science
Master File Table (MFT) is a crucial file in the NTFS file system that maintains records of all files in a volume, including their directory location, physical storage location, and metadata such as creation dates, access dates, and file size. It is
AI generated definition based on: Managing Information Security (Second Edition), 2014stamps, permissions, and data content, is stored either in MFT entries, or in space outside the MFT that is described by MFT entries.
https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table
The NTFS file system contains a file called the master file table, or MFT. There is at least one entry in the MFT for every file on an NTFS file system volume, including the MFT itself. All information about a file, including its size, time and date
On Tuesday, 04-02-2025 at 07:22 Stefan Monnier wrote:
Jan 13 19:46:06 eagle ntfs-3g[4262]: No free mft record for $MFT: NoHmm, MFT too small? A quick search showed me this (from a forum):
space left on device
AFAIK the MFT is implemented as a "normal" file; it can grow as needed
like any other file.
So, as long as there's room on the disk, it should not be "too small"
(tho maybe ntfs-3g just fails to implement some growth options,
e.g. maybe it only supports a contiguous MFT?).
Note that Dell computers we received were all delivered with 50% MFT reserve. We use many large files and reducing the MFT reserve to
12.5% saved these machines from being dog slow when they ‘filled up’ quickly. How much MFT space is needed? *My rule of thumb for
estimating is ‘number of files times 4k divided by total drive size’. The result is the percent of drive space needed for MFT. *As
you note, the actual requirement will vary… but you have to start
some place!
Note that this "reserve" is only a strategy to reduce the risk of
needing to use a fragmented MFT (https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/ntfs-reserves-space-for-mft):
Because of the importance of the MFT to NTFS and the possible impact
on performance if this file becomes highly fragmented, NTFS makes
a special effort to keep this file contiguous. NTFS reserves 12.5
percent of the volume for exclusive use of the MFT until and unless
the remainder of the volume is used up. Thus, space for files and
directories is not allocated from this MFT zone until all other
space is allocated first.
So the size of the "MFT reserve" can impact performance but should never cause a disk to appear full when it isn't.
Stefan
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 157:24:03 |
| Calls: | 12,093 |
| Calls today: | 1 |
| Files: | 15,000 |
| Messages: | 6,517,751 |