med-mastodon.com is one of the many independent Mastodon servers you can use to participate in the fediverse.
Medical community on Mastodon

Administered by:

Server stats:

364
active users

#exfat

0 posts0 participants0 posts today

Linux 6.15’s exFAT file deletion performance boosted

A recent development in the upcoming Linux 6.15 kernel has been spotted, because there was a big improvement to the exFAT file system implementation in relation to how it deletes the files when the “discard” mount option is used. This improvement significantly saves time as a test file after the merge has been deleted in 1.6 seconds, compared to more than 4 minutes of the total time taken.

This pull request makes sure that, upon file deletion, it discards a group of contiguous clusters (that is, clusters that are next to each other) in batch instead of discarding them one by one. This was because in prior kernels, such as 6.14, “if the discard mount option is enabled, the file’s clusters are discarded when they are freed. Discarding clusters one by one will significantly reduce performance. Poor performance may cause soft lockup when lots of clusters are freed.”

The change has been introduced in commit a36e0ab. Since then, the pull request has been merged to the kernel and it will be integrated to the first release candidate of Linux 6.15. A simple performance benchmark has been verified with the following commands:

# truncate -s 80G /mnt/file# time rm /mnt/file

In detail, the performance of this filesystem without this commit is poor, totalling about 4 minutes and 46 seconds in real time, with 12 seconds of system time. In contrast to the patched kernel, it totals about 1 second in real time, with 17 milliseconds of system time.

It’s a huge improvement!

Image by diana.grytsku on Freepik

Replied in thread

@timoruppell As it turns out it was about the filesystem format. While exFAT supports millions of files per dir and huge partitions, #macos writing to #exFAT is just very slow (and also appears to slow down the more you write).

Reformatting external disks with #APFS made a huge difference - maybe 10 times faster writes and no slowing down during the huge 7z file extraction process.

Extraction toos 5-6 days to exFAT formatted disk and only 6 hours to APFS formatted disk.

#exFAT tiene problemas de patentes en EEUU. De los sistemas operativos libres sólo los que utilizan núcleo #Linux están cubiertos por la excepción de patentes de #Microsoft. Véase definición de «sistema Linux» en la #OIN y el acuerdo de licencia: openinventionnetwork.com/joini

Los discos duros externos los formateo con sistemas de archivos libres.

Fuera de EEUU de momento no tendríamos problemas. Aún así es mejor utilizar sistemas de archivos libres. Siempre puedes instalarle el driver #ext4, #btrfs o el que sea a #Windows. Lo contrario no ocurre.

Recomendar utilizar #exFAT bajo la excusa de la compatibilidad con Windows no tiene sentido. Es contraproducente.

Open Invention NetworkOIN License Agreement - Open Invention NetworkBy signing the agreement, community members formally commit to share their Linux System patents / applications with all OIN community members free of charge

Купил microSD на 64Гб на wildberries за 400 рублей. Вроде Smartbay. Вроде, в фирменной упоковке. Но дёшево. Засунул в свой кнопочный Philips. Сразу начала читаться и писаться успешно. Таблица разделов в порядке.

Через несколько месяцев начал бекапить на неё файлы и файловая система начала сыпаться через какое-то время. При этом на работе, каждый раз как запущу fsck.vfat так какие-то ошибки обнаружатся.

Ну, хорошо, переразбил её на 3Гб раздел вначале в fat32 для телефона, и ещё 20Гб для начала под ext4 для бекапов. Вроде нормально читалось и писалось в оба раздела. Попытался создать третий раздел на остальное пространство, и таблица разделов потёрлась при записи изменений. Testdisk и gpart успешно находят, восстанавливают и записывают таблицу разделов. Но она куда-то "исчезает". Мистика какая-то.

Хрен с ним. Форматирую телефоном флешку. Смотрю таблицу разделов, а там бардак. Монтирую всю флешку (т.е. /dev/sdb) как раздел exFat и успешно она монтируется, пишется и читается. Думаю, вот почему у меня поначалу файловая система сыпалась. Яж её как раздел монтировал! Теперь-то будет всё нормально.

Бекаплю файлы спокойно. Через некоторое время файловая система опять сыпется. Думаю хрен с ним, форматирую всю флешку под reiserfs. По моему опыту эта файловая система лучше всего восстанавливается после любых сбоев. Копирую файлы и да, через некоторое время файловая система ломается, но --rebuild-tree полностью всё восстанавливает. 99% всё в целости и сохранности. Страдают только последне-записанные файлы.

Вот думаю, то ли контроллер флешки глючный и карточка бракованная? То ли мой кнопочный Philips "встревает" в процессы записи/чтения? Может купить переходник или картридер и проверить?...

Можно, конечно, купить просто новую флешку, качественную и подороже. Но я же программист - мы лёгких путей не ищем. И у меня появилась мысль содержимое файлов писать напрямую на диапазоны секторов через dd. А информацию сохранять где какой файл в текстовый файлик. И контрольную сумму тоже сохранять. После чтения проверять по ней: если не совпала - ну ладно, не повезло и либо заново перезаписать, либо попрощаться. А файлик текстовый со где что записано естественно пересылать надёжными путями. Хотя можно тоже его записывать в определённый диапазон секторов. Или даже в 2а диапазона. Но это уже похоже какая-то файловая система получается прям)

Replied to Henry

@hl
At least for #FreeBSD, #ExFAT mandates to install driver, sysutils/fusefs-exfat (and maybe additionally, sysutils/exfat-utils).
They would NOT merged into base system forever, because of conflicting license, unless re-licensed under any of BSD-compatible licenses and patents granted freely.
So #FAT32 would be the choice, although its limitations about large file systems. At worse, #FAT16, as I'm not at all sure about #MacOS.
#Linux would not have licensing issue, but would still have patent issue for #ExFAT.

Replied in thread

@dmerej Thanks for confirming my lack of confidence in filesystems not native to Linux.

Actually my new drive is exFAT. I dug a bit and found Arch sees all permissions granted on every file on the drive. Also, stat -f shows the actual cluster Block size: 131072, which wastes a ton of space for things like tiny Node modules! (All the other disk info commands show 4096, which is definitely wrong!)

So I've set up a separate little EXT4 SSD for the 'systemy' parts of my backup.

@glightly
I understand such a desire/user story, but this is better be done in a different way.
Why?
1. This is an _mostly_ undocumented feature of the #MacOS filesystem, so it barely used by MacOS application.
2. Content metadata should be bound to the file, not to the filesystem, cause otherwise you need all different filesystems to be interoperable (eg Windows #NTFS, MacOS #APFS and something like an #exFAT on your flash drive).

And there is more!