Закончились иноды в /var

Много файлов создадутся легко...

я понмиаю что это не ключевая фраза текста.. но всё равно отпишу что создаётся у меня там (на btrfs) много файлов — не так уж и легко...

миллион уже несколько (примерно пару) часов всё создаётся и создаётся :-)

Они в любом случае занимают 4К.

Размер блока задаётся, братюнь.

С мелкими файлами работай на рамдиске, братюнь — будет ускорение на неск. порядков.

Мифы мифы https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=...

что ты этим хотел сказать? То, что последний фикс в EXT4 был 8 дней назад, а в NTFS 8 лет назад минимум? Это да, круто.

на df -i кстате там да — нули

оно на райзере не имеет смысла. там другая структура.

Они в любом случае занимают 4К.

Размер блока задаётся, братюнь.

спасибо, я в курсе. Вот ты и задавай. А мне 4К больше любо.

ЗЫЖ только когда задашь, не вздумай тестировать, а то результаты там будут как у FAT12.

С мелкими файлами работай на рамдиске, братюнь — будет ускорение на неск. порядков.

YES!!!1

самый грамотный совет ТСу - кинь в память бобину своего экзима. И проблема решиться.

С мелкими файлами работай на рамдиске, братюнь — будет ускорение на неск. порядков.

спасиб за совет, дружище аноним. но рам-диск может потерять все мои файлы если выключить случайно комп

оно на райзере не имеет смысла. там другая структура.

в этой теме я олецетворяю btrfs :)

Для этого ups есть, бро.

Если ты не знаешь, почитай Кнута, там есть и формула, и её вывод

Ты решал задачу с сортировкой магнитной ленты? Даже если да, реши ещё раз, поймёшь, о чём я толкую.

размер файлов не имеет значения. Они в любом случае занимают 4К

Это неправда. Вряд ли это можно назвать ложью, если ты в это веришь сам. Пустой файл занимает место только в таблице инодов, блоков под него не выделяется. В новых ядрах в ext4 маленькие файлы (около 100 байт) целиком хранятся в инодах.

можешь сам посмотреть что там в EXT4

Я и смотрю, а ты, к сожалению, нет. Твои слова пустые, доказательств в виде кода ты привести не можешь.

Какую практическую ценность имеет данный результат, и для кого?

В .thumbnails скапливается больше 30 тысяч файлов. Каталог фрагментирован и из-за этого я славливаю тормоза там, где их не должно быть. Кстати, да, до 6000 кадров в виде отдельных картинок в одном каталоге — один из моих типичных сценариев использования. Так что как минимум, для меня.

На SSD получаются точно такие же(качественно)

А вот тут явное враньё. Несмотря на твою одержимость Кнутом, ты не можешь не понимать, что указанные им алгоритмы и их оценки применимы только для ОЗУ, где можно считать, что читать-писать можно словами. Если экстраполировать твоего Кнута на SSD, то TRIM не нужен, всё решают весёлые логарифмы. На деле это не так; наружу лезут детали реализации. Просто твой взор замылился, и ты этого не видишь. Эти «проблемы» решены за тебя и ты можешь продолжать жить в мире идеальных алгоритмических сложностей, где есть только О большое и нет мультипликативных констант.

в этой теме я олецетворяю btrfs

ну вот и расскажи, что там с инодами в btrfs? Я смотрю, если их много, то тормозит, но как-то работает. В EXT4 не тормозит, но их нельзя делать больше максимума, который задаётся при форматировании. Много задавать тоже нельзя, ибо место они жрут в любом случае. В btrfs как я понял они динамически выделяются?

Ты решал задачу с сортировкой магнитной ленты? Даже если да, реши ещё раз, поймёшь, о чём я толкую.

я прекрасно понимаю о чём ты. Да, скорость доступа у HDD намного ниже, вот только твоя ошибка в том, что ты почему-то считаешь, что для доступа к файлу надо каждый раз читать этот каталог и собирать по кусочкам. Не надо. Достаточно всего один раз прочитать, 21Мб - это мелочь на сегодня. Да и 10 лет назад это немного было. Кроме того, readdir распаковывает каталог в линейную структуру, этого для доступа тоже не надо, open(2) без этого обходится.

Это неправда. Вряд ли это можно назвать ложью, если ты в это веришь сам. Пустой файл занимает место только в таблице инодов, блоков под него не выделяется. В новых ядрах в ext4 маленькие файлы (около 100 байт) целиком хранятся в инодах.

$ du -sxh .
2,3G	.
$ ls -ldh .
drwxr-xr-x 2 drb users 21M марта 22 09:51 ./

если-бы это было правдой, каталог не занимал-бы 2.3Gb

короткие симлинки - да, хранятся, и занимают 0 байт. А вот регулярные файлы - нет. Если что ядро 3.7.1 ваниль.

В .thumbnails скапливается больше 30 тысяч файлов.

я не знаю как в райзере, но в EXT4 файлы занимают 4К минимум.

А вот тут явное враньё. Несмотря на твою одержимость Кнутом, ты не можешь не понимать, что указанные им алгоритмы и их оценки применимы только для ОЗУ, где можно считать, что читать-писать можно словами.

сам сказал, что у Кнута не только про ОЗУ было. Но и про ленты.

Если экстраполировать твоего Кнута на SSD, то TRIM не нужен, всё решают весёлые логарифмы.

не нужен. Для чтения. И для записи тоже не нужен. А вот для стирания - таки нужен.

На деле это не так; наружу лезут детали реализации. Просто твой взор замылился, и ты этого не видишь. Эти «проблемы» решены за тебя и ты можешь продолжать жить в мире идеальных алгоритмических сложностей, где есть только О большое и нет мультипликативных констант.

не лезут. Я прекрасно знаю, что флешки как не умели стирать, так и не умеют. До сих пор. TRIM не решает проблему стирания, а только откладывает её в фон. Однако это никак НЕ влияет на скорость доступа и скорость вставки. Вот с удалением - проблема, да. Всё просто - каталог 1М раз должен переписаться, и свободные острова быстро кончаются. Их надо стирать, но они кончились, и потому их надо в RT стирать, и ждать пока сотрутся. Именно потому(см. выше) за час я смог удалить всего 400К файлов.

Всё остальное - в точности по Кнуту, логарифмами и О большим. И никаких эльфов.

ну вот и расскажи

тыг я же не разбираюсь :)

с утра сделал скриптик — http://goo.gl/PEM5o .. включил его на миллион файлов — прошло уже несколько часов как он выполняется... больше ничего казать не могу :)

Я и смотрю, а ты, к сожалению, нет. Твои слова пустые, доказательств в виде кода ты привести не можешь.

какой код тебе нужен? код ext4 у тебя есть. теоретические выкладки есть у Кнута. Замеры см. выше у меня. Мои выводы со всем этим согласуются. Твои - нет. Поищи прошлые мои споры с тобой, там были замеры для HDD.

Единственное, что влияет на теорию - кривизна железа. HDD должен головками 3 часа дёргать, а SSD 3 часа стирает острова. Но в обоих случаях, для типичных юзкейсов, это не имеет значения.

PS: да, в случае вставки, каталог в EXT4 _добавляется_, а НЕ переписывается. Потому стирать ничего не надо, и в SSD это тоже быстро. Впрочем, как и в HDD, там при append only фрагментация очень мала(ну сравнительно - сотни фрагментов это немного для миллионов файлов)

ты его хоть протестировал на 9001 файле?

нет :) ..

ну на 100 штуках только.. эт да.. но 100 файлов не создают убийц :)

ну на 100 штуках только.. эт да.. но 100 файлов не создают убийц

похоже каталог действительно не уменьшается, но скорость доступа очень мала, и потому роли это не играет. В крайнем случае, можно просто пересоздать такой каталог ручками, если так уж хочется делать там ls каждые 5 минут.

Ты решал задачу с сортировкой магнитной ленты?

я прекрасно понимаю о чём ты

Так решал или нет?

короткие симлинки - да, хранятся, и занимают 0 байт. А вот регулярные файлы - нет.

Теоретик :) Код смотри: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/...

я не знаю как в райзере, но в EXT4

... ты тоже не знаешь.

Я прекрасно знаю, что флешки как не умели стирать, так и не

умеют.

и ждать пока сотрутся

Не вижу проявлений знания. Стирание NAND иногда быстрее записи, но обычно того же порядка. А ты говоришь, что оно медленное. Что ты вообще знаешь о NAND-flash?

не лезут.

И тут же следом

Именно потому(см. выше) за час я смог удалить всего 400К файлов.

Это даже не взаимоисключающие параграфы, это взаимоисключающий абзац.

какой код тебе нужен?

Ссылка на функцию, код которой подтвердит твои слова.

Поищи прошлые мои споры с тобой, там были замеры для HDD.

В наших прошлых спорах замеры были в основном мои (может быть и только мои). Так что поищи сам и дай ссылку, если найдёшь.

да, в случае вставки, каталог в EXT4 _добавляется_, а НЕ переписывается

мда... Вот здесь хорошо бы увидеть от тебя куски кода из ext4, подтверждающие то, что ты сказал. Глядишь, пока ищешь и одумаешься.

с утра сделал скриптик

Файлы достаточно делать пустые, а удалять можно и по очереди.

import time
from random import randrange
import random

alphabet = list(range(ord('a'), ord('z')+1))
alphabet += list(range(ord('A'), ord('Z')+1))
alphabet += list(range(ord('0'), ord('9')+1))
alphabet = [chr(x) for x in alphabet]

t_start = time.time()

k = 0

for i in range(1000):
    for i2 in xrange(1000):
        name = '' + ''.join([random.choice(alphabet) for idx in range(8)])
        f = open(name, 'wb')
        f.close()
        k = k + 1
    t_stop = time.time();
    print '%04d, %f' % (i, t_stop - t_start)
    t_start = t_stop

Бро, мб я чёто не понимаю, но тебе нужно
import string
list(string.hexdigits)
и всё остальное в том же духе.

А ещё лучше всё это заменить на
uuid.uuid4().hex[:8]

запустил и этот скрипт тоже :) [без изменений, но через | tee ../log.txt]

правда прошлый то ещё не закончил выполняться..

кстате да — пустые файлы создаются на во много раз быстрее.. прям на прядок

всего несколько минут и собственно результат — http://goo.gl/EvIJw ..

..ксате говоря мне нравиться что в среднем время создания последних порций файлов всего лишь в 2~3 раза больше чем время создания первых порций файлов

но тебе нужно

Ага, можно и так.

одно могу точно сказать --

во время операции...

$ find t2/ -type f -delete # где ``t2/`` это директория-миллионер :)

я просто чудом написал это сообщение :) .. незабываемое приключение!

Так решал или нет?

да.

Теоретик :) Код смотри

в какой строке?

... ты тоже не знаешь.

хорошо. Как узнать, сколько места занимает файл?

Не вижу проявлений знания. Стирание NAND иногда быстрее записи, но обычно того же порядка. А ты говоришь, что оно медленное. Что ты вообще знаешь о NAND-flash?

делись пруфом.

не лезут.

И тут же следом

Именно потому(см. выше) за час я смог удалить всего 400К файлов.

Это даже не взаимоисключающие параграфы, это взаимоисключающий абзац.

что чего взаимоисключает? ЯННП.

Ссылка на функцию, код которой подтвердит твои слова.

ты не согласен - ты и опровергни. А то du с тобой несогласна. Ей я доверяю больше, чем тебе, извини.

да, в случае вставки, каталог в EXT4 _добавляется_, а НЕ переписывается

мда... Вот здесь хорошо бы увидеть от тебя куски кода из ext4, подтверждающие то, что ты сказал. Глядишь, пока ищешь и одумаешься.

искать мне лень, в качестве косвенного подтверждения, попробуй поставить append only на каталог, сможешь создавать там файлы, но удалить их не сможешь. Видать открываются они с O_APPEND.

А вообще - если ты такой умный, и не согласен с моим объяснением, огласи своё: почему 1М файлов создаются за секунды, а удаляются часами?

в какой строке?

213, 521

хорошо. Как узнать, сколько места занимает файл?

du. Пустые файлы у меня занимают на диске 0 байт. Ядро у меня слишком старое для упаковки хвостов, ставить в виртуалку новое мне лень, но я больше верю Ts'o, чем тебе в этом вопросе :-)

делись пруфом.

datasheet на MT29F1GxxABB, запись страницы 250 мкс, стирание блока 2мс. В одном блоке 64 страницы. Стирание блока в итоге в 8 раз быстрее, чем его запись. Что, лень погуглить было?

что чего взаимоисключает?

В начале абзаца ты говоришь, что детали реализации не лезут наружу, а в конце описываешь эффекты этих деталей реализации, подтверждая, что они таки лезут.

в качестве косвенного подтверждения, попробуй поставить append only на каталог, сможешь создавать там файлы, но удалить их не сможешь. Видать открываются они с O_APPEND.

О, Небесная Дискета! Какой бред! Приводить поведение интерфейса в доказательство своей гипотезы о реализации.

огласи своё: почему 1М файлов создаются за секунды, а удаляются часами?

А я не знаю, гадать не хочу. Чтобы выяснить, надо код читать. Долго и упорно. А зачем это мне? Хочешь - читай. Найденный пруф проверить я смогу, а искать не буду.

А то du с тобой несогласна. Ей я доверяю больше, чем тебе, извини.

Океюшки. А я вижу код, вижу статьи на lwn. Себе я доказал, зачем мне доказывать тебе?

можно просто пересоздать такой каталог ручками

Пересоздать каталог ручками, переносить данные и форматировать после исчерпания инодов или при фрагментации ручками, задавать иноды тоже ручками. Какая современная ФС.

213, 521

блжад! у меня и файла нет такого! он 20 дек. появился: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/ext...

мы с Пэтом ещё не перешли. Слоупуки жеж. У меня от 17го дек.

du. Пустые файлы у меня занимают на диске 0 байт. Ядро у меня слишком старое для упаковки хвостов, ставить в виртуалку новое мне лень, но я больше верю Ts'o, чем тебе в этом вопросе :-)

про хвосты не в курсе. вот что stat пишет:

$ stat xaaalned
  Файл: «xaaalned»
  Размер: 100       	Блоков: 8          Блок В/В: 4096   обычный файл
Устройство: 807h/2055d	Inode: 743142      Ссылки: 1
Доступ: (0644/-rw-r--r--)  Uid: ( 1000/     drb)   Gid: (  100/   users)
Доступ: 2013-03-22 08:26:46.921426083 +0400
Модифицирован: 2013-03-22 08:26:46.921426083 +0400
Изменён: 2013-03-22 08:26:46.921426083 +0400
 Создан: -

$ du -h xaaalned
4,0K	xaaalned
$ du --apparent-size -h xaaalned
100	xaaalned

# до кучи uname -a
Linux ksu 3.7.1 #2 SMP Thu Dec 20 21:20:41 CST 2012 x86_64 Intel(R) Pentium(R) CPU G2020 @ 2.90GHz GenuineIntel GNU/Linux

datasheet на MT29F1GxxABB, запись страницы 250 мкс, стирание блока 2мс. В одном блоке 64 страницы. Стирание блока в итоге в 8 раз быстрее, чем его запись. Что, лень погуглить было?

facepalm

ты можешь понять простую вещь, что так будет в том, и только в том случае, если тебе нужно стереть именно ЭТИ страницы? А если из этих 64х половина - нужные? Правильно, тебе надо их куда-то перекинуть, а потом уж стереть. Так вот, суть TRIM как раз и заключается, что это перекидование и стирание идёт в фоне, и потому у тебя всегда есть запас чистых блоков. Потому запись идёт рандомно и быстро, т.к. вся свободная память за ночь очистилась(не только стёрлась, но и «дефрагментировалась»), и теперь мы имеем чистые блоки.

Это при записи. При удалении страницы удаляются рандомно, и мы имеем кучу грязных блоков, в которых половина страниц не нужны, но не успели стереться, ибо идёт непрерывная запись, да и стирать нельзя, до тех пор, пока мы половину нужных страниц не раскидаем по свободным блокам (которых ВНЕЗАПНО и нет).

Проблема SSD в том, что стереть можно только блок целиком, а пока его не сотрёшь, писать туда нельзя. Это не страшно, если запись редко происходит, и всегда есть резерв больших блоков. Не в этом жестоком тесте.

И да, твои сведения устарели - у меня несколько другие, лень гуглить, но у меня блоки больше страниц вмещают(256 ЕМНИП), потому очистить их намного сложнее и дольше. Ну и запись намного быстрее(up to 510MB/sec, явно не 250мкс/стр).

В начале абзаца ты говоришь, что детали реализации не лезут наружу, а в конце описываешь эффекты этих деталей реализации, подтверждая, что они таки лезут.

это если удалять ВСЕ 1М файлов. Кстати - на HDD это тоже на неделю, уже была тема на UFO, аффтор не я, если что.

Короче:

• в типичном юзкейсе: редкая вставка/удаление, частое чтение одного конкретного файла; каталог где МНОГО файлов на EXT4 работает быстро и хорошо, что на HDD, что на SSD.
• при создании БОЛЬШОГО количества файлов СРАЗУ на HDD они создаются достаточно быстро, хотя и не за секунды. На SSD за секунды, если конечно его перед этим не задрочили. Это не типичный юзкейс, но удобно в тестах.
• при удалении ВСЕХ файлов СРАЗУ - жуткие тормоза. И да, носитель блокируется, хоть SSD, хоть HDD. Количественно на HDD примерно также, как на SSD (если сравнить девайсы одного года выпуска).

О, Небесная Дискета! Какой бред! Приводить поведение интерфейса в доказательство своей гипотезы о реализации.

вообще-то моя гипотеза отлично подтверждается экспериментом. А детали интерфейса тебе так - на закуску.

А я не знаю, гадать не хочу. Чтобы выяснить, надо код читать. Долго и упорно. А зачем это мне? Хочешь - читай. Найденный пруф проверить я смогу, а искать не буду.

мне тоже лень. У меня - очевидное объяснение - при создании файла данные добавляются в каталог. Очевидно же! А при удалении - могут только переписываться. Есть другой способ? Как откусить кусок каталога из рандомного места? Самое простое - забить нулями, и записать «обратно». Но в SSD «обратно» не существует. Откуда и тормоза. Впрочем в HDD тоже тормоза, хотя и относительно небольшие - писать довольно много, 21Мб в кеш диска не влезет, придётся ждать, и так миллион раз. А дописать новое имя значительно быстрее.

Океюшки. А я вижу код, вижу статьи на lwn. Себе я доказал, зачем мне доказывать тебе?

дык этому коду месяца нет, оно ещё в релиз не попало вроде-бы. В любом случае, я ещё не в курсе, какой вариант ядра поставит Пэт, явно не этот.

Пересоздать каталог ручками

это для того, что-бы его ручками просматривать.

Для программ он отлично работает, не переживай. А вот если в дельфине зайти, то может и тормозить. Ещё не проверил.

переносить данные и форматировать после исчерпания инодов или при фрагментации ручками

если форматировать кривыми ручками - да. Опять. Дурная голова…

про хвосты не в курсе. вот что stat пишет:

facepalm

ты хоть понимаешь, что он у тебя не размера 0 байт? вот что пишут файл размером 0 байт

maloi@void:~$ stat 1    
  File: '1'
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: fe04h/65028d    Inode: 541512      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   maloi)   Gid: ( 1000/   maloi)
Access: 2013-03-22 23:11:30.716145142 +0400
Modify: 2013-03-22 23:11:30.716145142 +0400
Change: 2013-03-22 23:11:30.716145142 +0400
 Birth: -
maloi@void:~$ du 1
0       1
maloi@void:~$ uname -a
Linux void 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux

facepalm

Что, уже загуглил? :) Ты писал: «Их надо стирать, но они кончились, и потому их надо в RT стирать, и ждать пока сотрутся.» Если бы хоть что-то про Read-Modify-Write было, я бы слова не сказал. Но твои слова имеют прямой смысл: тормозит стирание. Может ты конечно что-то там подразумевал, но сказал именно так, как сказал.

И да, твои сведения устарели - у меня несколько другие

А ты погугли datasheet'ы на микросхемы в твоём SSD. Хе-хе.

Кстати - на HDD это тоже на неделю

Да ладно, часа два-три займёт всего

Для программ он отлично работает, не переживай. А вот если в дельфине зайти, то может и тормозить

Видимость работы, ага.

ты хоть понимаешь, что он у тебя не размера 0 байт?

facepalm

возвращаемся: нафейхуя нужно хранить 1000000 файлов в 0 байт???

Что, уже загуглил? :)

болеешь? я когда-то другое рассказывал?

Ты писал: «Их надо стирать, но они кончились, и потому их надо в RT стирать, и ждать пока сотрутся.» Если бы хоть что-то про Read-Modify-Write было, я бы слова не сказал. Но твои слова имеют прямой смысл: тормозит стирание. Может ты конечно что-то там подразумевал, но сказал именно так, как сказал.

да. тормозит стирание. что непонятно? ясное дело, что не стирание самих блоков с данными, я думал, тебе это очевидно. Если не очевидно - извини.

А ты погугли datasheet'ы на микросхемы в твоём SSD. Хе-хе.

а какие там микросхемы?

Да ладно, часа два-три займёт всего

не факт. сам писал про фрагментацию.

Для программ он отлично работает, не переживай. А вот если в дельфине зайти, то может и тормозить

Видимость работы, ага.

да. видимость. зачем тебе в дельфине/ls миллион файлов?

да. видимость. зачем тебе в дельфине/ls миллион файлов?

Какие миллион файлов? Он же пустой.

Запусти dpkg-reconfigure exim4-config, выбери разумные параметры (почта в один файл), перезагрузи конфиг exim'а, запусти exim -qf (пройти очередь ещё раз)

Немного освободилось времени, решил выполнить процитированное.

# tail /var/log/exim4/mainlog
2013-03-23 02:15:13 End queue run: pid=13151
2013-03-23 02:23:22 Start queue run: pid=19486 -qf
2013-03-23 02:23:22 1UItXJ-0000Ca-Cp Message is frozen
2013-03-23 02:23:22 End queue run: pid=19486 -qf
2013-03-23 02:30:19 1UItXJ-0000Ca-Cp unfrozen by root
2013-03-23 02:30:31 Start queue run: pid=25050 -qf
2013-03-23 02:30:31 1UItXJ-0000Ca-Cp ** root@host. R=nonlocal: Mailing to remote domains not supported
2013-03-23 02:30:31 1UJCLv-0006W4-HF Error while reading message with no usable sender address (R=1UItXJ-0000Ca-Cp): at least one malformed recipient address: root@host. - domain missing or malformed
2013-03-23 02:30:31 1UItXJ-0000Ca-Cp Process failed (1) when writing error message to root@host. (frozen)
2013-03-23 02:30:31 End queue run: pid=25050 -qf

какой код тебе нужен?

Тот самый код где у тебя люто тормозило. Ведь ты вра.. то есть проверял

резолвинга host скорее всего

Если не очевидно - извини.

Ты единственный, кому это очевидно. Стирание оно и есть стирание. Это не запись и не чтение, это отдельный процесс.

а какие там микросхемы?

открой да посмотри.

не факт.

факт. Вчера вечером разные варианты пробовал, за три часа (с перерывами) всё закончилось. Так что менее трёх часов. Или ты по Кнуту посчитал? :-D

Какие миллион файлов? Он же пустой.

а… ты проверил в сказку про каталог-убийцу? такой большой, а в сказки веришь:

$ time ls -ld b
drwxr-xr-x 2 drb users 21815296 марта 23 01:19 b/

real	0m0.012s
user	0m0.002s
sys	0m0.008s
$ time ls -l b
итого 0
-rw-r--r-- 1 drb users 0 марта 22 09:41 zzz

real	0m0.017s
user	0m0.001s
sys	0m0.013s

Ты единственный, кому это очевидно. Стирание оно и есть стирание. Это не запись и не чтение, это отдельный процесс.

мне одному очевидно, что отдельный «ненужный» процесс может тормозить всю систему тогда, и только тогда, когда он делает что-то _необходимое_ всей системе?

открой да посмотри.

купи мне такой, я и открою. Зачем мне терять гарантию?

факт. Вчера вечером разные варианты пробовал, за три часа (с перерывами) всё закончилось. Так что менее трёх часов. Или ты по Кнуту посчитал?

нет. я по опыту знаю. диски они разные бывают, ты со всеми проверил? Компьютеры, кстати, тоже.

i-rinat пустой файл занимает на диске 0 байт

drBatty нет, даже пустой файл занимает минимум 4 КБ на диске, вот вывод команды.

maloi у тебя файл не пустой

drBatty нахуя нужны пустые файлы?

перечитывай это до тех пор, пока до тебя не дойдет, что ты споришь со своими голосами в голове.

чувак, я не знаю, что ты сделал со своей ext4, но у меня таких тормозов никогда в жизни не было