Everyone's gonna give you shit for this answer and there's a hundred things I could tell you about their software that pisses me off, but the bar is so low for software these days, their stuff is still in the high end of quality (they need to do a lot to get back to where they were 10 years ago though)
Only other software I regularly use that I think is overall high quality and I enjoy using are the JetBrains IDEs, and the Telegram mobile app (though the Premium upselling has gotten kinda gross the past few years)
I never used ATA Security commands with NVME or SSDs, but I did use them with spinning rust ATA and SATA drives. I even had a BIOS module added into the firmware of the motherboard to manage ATA Security [0].
I have a few comments to make:
1)
Erase operation is in fact a succession of two commands: ATA Security Erase Pepare and ATA Security Erase Execute. No other command can be sent between these two, so any disk access by the OS after the first command would cause the second to fail.
2)
ATA Security commands are usually blocked ("frozen") after boot if the drive has no password or was password-unlocked. That means the drive will not accept commands to set/change password or erase until power-cycled. That is a full power cut, not just a reset-drive command.
This feature prevents a virus from passwording or erasing your drive. Yes, it can still crypto-lock or erase your drive via ordinary disk writes, but that takes hours for the whole drive, while ATA Security Erase or setting a password takes a millisecond or so.
The ATA Security Freeze command is sent to the drive either by the BIOS/UEFI (my BIOS didn't do this, but probably all laptops have it as part of their BIOS/UEFI Security features), by a BIOS module (my desktop BIOS didn't have it), by the operating system as part of drive encryption features, or by an antivirus. Also, the drive firmware may have a timer to automatically freeze ATA Security commands after a timeout if it doesn't receive the explicit command from the host.
Power cycling by putting the system to sleep and then wake up will NOT work, because if the drive is locked with a password, it needs to be unlocked BEFORE the firmware/ACPI gives control back to the operating system. Otherwise, the OS would no longer be able to access the disk after wake up. So, the BIOS/UEFI/ACPI, if it supports ATA Security at all, will automatically freeze ATA Security commands again during wake-up, just as it did during cold boot.
In conclusion, the dive must be physically unplugged from power and then hot-plugged. Or start the computer without it, and hot-plug it after boot.
3)
Many (most?) USB adapters don't support ATA commands at all. They'll just emulate a USB mass storage with no direct access to the drive. What you need is an adapter that supports UAS (USB Attached SCSI). And even then, I'm not sure ATA Security commands have a SCSI equivalent so they can be translated.
The best option here is to hot-plug into a real SATA port on the motherboard or PCI/PCIe controller. NOT via USB.
I had nothing but problems since that was introduced in 6.1. It seems that the kernel prefers to compact/defrag memory, repeatedly, each time freezing everything 1-2 seconds, rather than releasing some disk cache memory or swapping out.
OpenWrt on some devices such as Turris Omnia writes the squashfs (mounted as RO root fs) in the "root" partition and then, immediately after, in the same partition, it writes a jffs2 (mounted as RW overlayfs). So it can be done.
I don't know how Linux driver updates FAT, but if it doesn't do it the way DOS did, then it's a bug that puts data at risk.
1) Allocate space in FAT#2, 2) Write data in file, 3) Allocate space in FAT#1, 4) Update directory entry (file size), 5) Update free space count.
Rename in FAT is an atomic operation. Overwrite old name with new name in the directory entry, which is just 1 sector write (or 2 if it has a long file name too).
No, the VFAT driver doesn't do anything even slightly resembling that.
In general "what DOS did" doesn't cut for a modern system with page and dentry caches and multiple tasks accessing the filesystem without completely horrible performance. I would be really surprised if Windows handled all those cases right with disk caching enabled.
While rename can be atomic in some cases, it cannot be in the case of cross directory renames or when the new filename doesn't fit in the existing directory sector.
> No, the VFAT driver doesn't do anything even slightly resembling that.
Which driver? DOS? FreeDOS? Linux? Did you study any of them?
> While rename can be atomic in some cases, it cannot be in the case of cross directory renames or when the new filename doesn't fit in the existing directory sector.
That's a "move". Yes, you would need to write 2-6 sectors in that case.
For short filenames, the new filename can't not fit the directory cluster, because short file names are fixed 8.3 characters, pre-allocated. A long file name can occupy up to 10 consecutive directory entries out of the 16 fixed entries each directory sector (512B) has. So, an in-place rename of a LFN can write 2 sectors maximum (or 1KB).
Considering that all current drives use 4KB sectors at least (a lot larger if you consider the erase block of a SSD) the rename opearation is still atomic in 99% of cases. Only one physical sector is written.
The most complicated rename operation would be if the LFN needs an extra cluster for the directory, or is shorter and one cluster is freed. In that case, there are usually 2 more 1-sector writes to the FAT tables.
Edit: I corrected some sector vs. cluster confusion.
FAT can be made tolerant form the driver just like a journaled FS:
1) mark blocks allocated in first FAT
If a crash occurs here, then data written is incomplete, so write FAT1 with data from FAT2 discarding all changes.
2) write data in sectors
If a crash occurs here, same as before, keep old file size.
3) update file size in the directory
This step is atomic - it's just one sector to update. If a crash occurs here (file size matches FAT1), copy FAT1 to FAT2 and keep the new file size.
4) mark blocks allocated in the second FAT
If a crash occurs here, write is complete, just calculate and update free space.
5) update free space
Could be great for video conferences.
reply