The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..., opennews (ok), 26-Окт-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


28. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –1 +/
Сообщение от Аноним (-), 26-Окт-12, 21:12 
Вы я вижу эксперт по архитектуре файловых систем.
Не взять Reiser4 потому что его даже поддерживать некому.
Не взять Reiser4 потому что не нужна модульная fs.
Прям все дураки в Kernel Team и не берут чудесную fs.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

30. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 26-Окт-12, 21:16 
> Прям все дураки в Kernel Team и не берут чудесную fs.

Ну разумеется! Ведь намного считать что "все пи...сы, а вот %s - ДАртаньян".

Ответить | Правка | Наверх | Cообщить модератору

33. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 26-Окт-12, 21:30 
> Ну разумеется! Ведь намного считать что "все пи...сы, а вот %s - ДАртаньян".

printf("все пи...сы, а вот %s - ДАртаньян", "Эдуард Шишкин")?

Ответить | Правка | Наверх | Cообщить модератору

43. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 27-Окт-12, 00:07 
> printf("все пи...сы, а вот %s - ДАртаньян", "Эдуард Шишкин")?

Вместо Эдуард Шишкин должна быть переменная, т.к. данным шаблоном оперирует не только он к сожалению :)

Ответить | Правка | Наверх | Cообщить модератору

53. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –1 +/
Сообщение от Аноним (-), 27-Окт-12, 04:29 
> Вместо Эдуард Шишкин должна быть переменная, т.к. данным шаблоном оперирует не только он к сожалению :)

Тео Цо и Крис Мейсон вроде в таких высказываниях не замечены.

Ответить | Правка | Наверх | Cообщить модератору

85. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 28-Окт-12, 05:51 
> Тео Цо и Крис Мейсон вроде в таких высказываниях не замечены.

Зато на опеннете например этот шаблон крайне популярен. У упомянутых то хватит ума не выставляться дураками. Но не все же такие умные :)

Ответить | Правка | Наверх | Cообщить модератору

35. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от oneonfire (?), 26-Окт-12, 21:50 
Одна лишь здесь достойная причина, не кому поддерживаеть, а все остальные просто не оправдание...
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

36. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 26-Окт-12, 22:07 
Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

44. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 27-Окт-12, 00:08 
> Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.

Так у этих сроду ресурсов ни на что нет. Учтя что доделывать это серьезно напрягает даже линуксоидов, упомянутые уж точно смогут что-то такое не в этой жизни и не в этой галактике.

Ответить | Правка | Наверх | Cообщить модератору

54. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 27-Окт-12, 04:31 
> Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.

freebsd, minix и прочие подобные проекты не смогут допилить даже то, что им жизненно необходимо. Так что не показатель.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

67. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –6 +/
Сообщение от nagualemail (ok), 28-Окт-12, 00:23 
>> Вот некому не вперся Reiser4, не freebsd не minix да вообще некому.
> freebsd, minix и прочие подобные проекты не смогут допилить даже то, что
> им жизненно необходимо. Так что не показатель.

Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают что такие фичи как Reiser4 жизненно необходимы в bsd :)))

Ответить | Правка | Наверх | Cообщить модератору

76. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 28-Окт-12, 04:05 
> Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают что такие фичи как Reiser4 жизненно необходимы в bsd :)))

При чем здесь Reiser4? Вот отсутствие полноценной виртуализации - really makes freebsd sucks. Но - не могут. Ни из солярки зоны, ни из линукса KVM.

Ответить | Правка | Наверх | Cообщить модератору

95. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –2 +/
Сообщение от nagualemail (ok), 28-Окт-12, 11:14 
>> Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают что такие фичи как Reiser4 жизненно необходимы в bsd :)))
> При чем здесь Reiser4? Вот отсутствие полноценной виртуализации - really makes freebsd
> sucks. Но - не могут. Ни из солярки зоны, ни из
> линукса KVM.

Было бы нужно - сделали бы.

Ответить | Правка | Наверх | Cообщить модератору

105. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +2 +/
Сообщение от AlexAT (ok), 28-Окт-12, 13:07 
> Было бы нужно - сделали бы.

Ну так о чем и речь. В серьезных применениях платформа мало кому интересна.

Ответить | Правка | Наверх | Cообщить модератору

121. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +1 +/
Сообщение от Аноним (-), 29-Окт-12, 06:02 
> Было бы нужно - сделали бы.

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

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

136. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –1 +/
Сообщение от nagualemail (ok), 29-Окт-12, 12:20 
>> Было бы нужно - сделали бы.
> Ну а энтерпрайзы повертели пальцем
> у виска да свалили на пингвины.

Кому нужно стабильно то vmware. Видал я как с kvm работают на дебиане - колются давятся плачут но жрут :))))


Ответить | Правка | Наверх | Cообщить модератору

154. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 29-Окт-12, 17:20 
> Кому нужно стабильно то vmware.

Спасибо, конечно, но он стоит денег. При том что у меня KVM нахаляву в системе есть - я что, дурак чтоли - платить вмварщикам за их блобье?

> Видал я как с kvm работают на дебиане - колются давятся плачут но жрут :))))

На дебиане с их древними ядрами и неизвестной квалификацией админов - хз, а я на регулярной основе гоняю пачки KVMных виртуалок в не сильно древних убунтах. Нормально работает. Если что, я видел туеву хучу гипервизоров и контейнеров всех мастей - могу сравнивать. Вполне нормальный гипервизор.

Ответить | Правка | Наверх | Cообщить модератору

199. "Теодор Тцо отказался от предложений по стабилизации ФС..."  +/
Сообщение от arisu (ok), 31-Окт-12, 16:19 
> Спасибо, конечно, но он стоит денег.

не только это. вот ещё забавка:
http://www.intelliadmin.com/index.php/2008/07/vmwares-insane.../
для пруфа, что не протухло:
http://www.vmware.com/download/eula/player_download.html
http://www.vmware.com/download/eula/esx_server.html
дальше интересующиеся найдут сами.

чо, как, есть желающие ещё в это вляпываться?

Ответить | Правка | Наверх | Cообщить модератору

200. "Теодор Тцо отказался от предложений по стабилизации ФС..."  +/
Сообщение от nagualemail (ok), 31-Окт-12, 17:10 
>> Спасибо, конечно, но он стоит денег.
> не только это. вот ещё забавка:
> http://www.intelliadmin.com/index.php/2008/07/vmwares-insane.../
> для пруфа, что не протухло:
> http://www.vmware.com/download/eula/player_download.html
> http://www.vmware.com/download/eula/esx_server.html
> дальше интересующиеся найдут сами.
> чо, как, есть желающие ещё в это вляпываться?

А что там не так в двух словах ?

Ответить | Правка | Наверх | Cообщить модератору

202. "Теодор Тцо отказался от предложений по стабилизации ФС..."  +1 +/
Сообщение от arisu (ok), 31-Окт-12, 18:28 
> А что там не так в двух словах ?

ты обязан хранить данные по тому, как используешь продукты vmware как минимум за два года, и ребята из вмвари в любой момент по желанию левой пятки могут к тебе прийти и сделать полный аудит твоей техники и использования их продуктов — на предмет «а вдруг ты что-то не так сделал, гад?!» и отказаться нельзя, потому что ты по лицензии согласился, когда ставил/покупал.

Ответить | Правка | Наверх | Cообщить модератору

203. "Теодор Тцо отказался от предложений по стабилизации ФС..."  +/
Сообщение от nagualemail (ok), 01-Ноя-12, 01:06 
>> Спасибо, конечно, но он стоит денег.
> не только это. вот ещё забавка:
> http://www.intelliadmin.com/index.php/2008/07/vmwares-insane.../
> для пруфа, что не протухло:
> http://www.vmware.com/download/eula/player_download.html
> http://www.vmware.com/download/eula/esx_server.html
> дальше интересующиеся найдут сами.
> чо, как, есть желающие ещё в это вляпываться?

Срочная новость - яша сдох !!!

http://yandex.ua/yandsearch?text=freebsd+%2Fsbin%2...

Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

224. "Теодор Тцо отказался от предложений по стабилизации ФС..."  +/
Сообщение от Аноним (-), 01-Ноя-12, 18:44 
> не только это. вот ещё забавка:

Кэпу присуждается однозначный EPIC WIN за внимательность и дотошность. Крутота! :)

> чо, как, есть желающие ещё в это вляпываться?

Вот nagual пусть и хранит данные для аудитчиков из вмвари. Знаешь, после таких копирастических лицензий визги о несвободе GPL выглядят особенно умильно :). Не хочу ничего сказать но мне намного проще выложить сорц и даже состав материала моих трусов, если надо, чем страдать настолько эпическим копирастическим маразмом.

Ответить | Правка | К родителю #199 | Наверх | Cообщить модератору

225. "Теодор Тцо отказался от предложений по стабилизации ФС..."  +2 +/
Сообщение от arisu (ok), 01-Ноя-12, 18:49 
> Кэпу присуждается однозначный EPIC WIN за внимательность и дотошность. Крутота! :)

справедливости ради — это ребята на maemo.org дотошные. а я, как нормальный кэп, просто принёс это сюда.

Ответить | Правка | Наверх | Cообщить модератору

260. "Теодор Тцо отказался от предложений по стабилизации ФС..."  +/
Сообщение от Аноним (-), 04-Ноя-12, 22:05 
> справедливости ради — это ребята на maemo.org дотошные. а я, как нормальный
> кэп, просто принёс это сюда.

Справедливости ради, ты это там нашел хотя-бы. В любом случае, очень полезное наблюдение :)

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

86. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 28-Окт-12, 05:58 
> Разработчики freebsd неграмотные и не читают всяких анонимусов а потому не знают
> что такие фичи как Reiser4 жизненно необходимы в bsd :)))

Так я и говорю - им бы свои проблемы разгрести, не то что чужие.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

69. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –1 +/
Сообщение от nagualemail (ok), 28-Окт-12, 00:28 
> Вы я вижу эксперт по архитектуре файловых систем.
> Не взять Reiser4 потому что его даже поддерживать некому.
> Не взять Reiser4 потому что не нужна модульная fs.
> Прям все дураки в Kernel Team и не берут чудесную fs.

Вопрос к Ыксперту - подскажите библиотеку - функцию которая позволит например удалить блок в середине файла не перечитывая перезаписывая хвост ? :))

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

87. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +1 +/
Сообщение от Аноним (-), 28-Окт-12, 06:01 
> Вопрос к Ыксперту - подскажите библиотеку - функцию которая позволит например удалить
> блок в середине файла не перечитывая перезаписывая хвост ? :))

В Linux hole punching делается как-то так: http://lwn.net/Articles/415889/
Ну а найти в какой либе живет fallocate() будет твоим домашним заданием :)

Ответить | Правка | Наверх | Cообщить модератору

116. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –2 +/
Сообщение от nagualemail (ok), 28-Окт-12, 23:51 
>> Вопрос к Ыксперту - подскажите библиотеку - функцию которая позволит например удалить
>> блок в середине файла не перечитывая перезаписывая хвост ? :))
> В Linux hole punching делается как-то так: http://lwn.net/Articles/415889/
> Ну а найти в какой либе живет fallocate() будет твоим домашним заданием
> :)

fallocate этож не то :)

Ответить | Правка | Наверх | Cообщить модератору

122. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +1 +/
Сообщение от Аноним (-), 29-Окт-12, 06:08 
> fallocate этож не то :)

Я по-моему предельно ясно ткнул на сообщение в LWN где показано что добавили новые флаги к этому сисколу и стало как раз то: освобождение блоков в середине файла без какой либо перетряски всего остального. Как заказывали. Оно в принципе и блочному сторажу потом еще и TRIM может скинуть по этому поводу на другом уровне, чтоб накопитель мог почистить неиспользуемые блоки. Называется эта технология "hole punching", в пингвине данное расширение сискола - точно есть. Понимается довольно большим списком ФСов на данные момент, а в 3.7 ядре это расширение запилили и в btrfs до кучи. Как подобные финты ушами в *BSD делать - а это вы сами разбирайтесь. Вот и посмотрим заодно у кого мозгов больше: у убунтушников или у пользователей BSD :)

//Да, если что я хоть и убунтуец, но подергать сисколы совсем не против :)

Ответить | Правка | Наверх | Cообщить модератору

137. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –1 +/
Сообщение от nagualemail (ok), 29-Окт-12, 12:22 
>[оверквотинг удален]
> Как заказывали. Оно в принципе и блочному сторажу потом еще и
> TRIM может скинуть по этому поводу на другом уровне, чтоб накопитель
> мог почистить неиспользуемые блоки. Называется эта технология "hole punching", в пингвине
> данное расширение сискола - точно есть. Понимается довольно большим списком ФСов
> на данные момент, а в 3.7 ядре это расширение запилили и
> в btrfs до кучи. Как подобные финты ушами в *BSD делать
> - а это вы сами разбирайтесь. Вот и посмотрим заодно у
> кого мозгов больше: у убунтушников или у пользователей BSD :)
> //Да, если что я хоть и убунтуец, но подергать сисколы совсем не
> против :)

posix_fallocate точно не оно но ладно. А выделяет блок любой длины или по размеру блока фс ? ;)
Кстати а как обратная функция называется - вырезать из середины файла блок произвольной длины в другой файл ?

Ответить | Правка | Наверх | Cообщить модератору

155. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +1 +/
Сообщение от Аноним (-), 29-Окт-12, 17:26 
> posix_fallocate точно не оно но ладно.

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

> А выделяет блок любой длины или по размеру блока фс ? ;)

А это уже программер сам как-нибудь должен в апликухе, если оно ему надо.

> Кстати а как обратная функция называется - вырезать из середины файла блок
> произвольной длины в другой файл ?

А тут уже одним сисколом не отвертишься, понадобится программа которая их дернет в произвольном порядке. В первом приближении таковым можно посчитать обычный dd которым вы так козыряли ;). Если за каким-то надо еще и дестроить то что он скопировал - ну, придется допатчить. Правда я не понимаю нафиг это надо, но...

Ответить | Правка | Наверх | Cообщить модератору

162. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от nagualemail (ok), 29-Окт-12, 18:55 
>> А выделяет блок любой длины или по размеру блока фс ? ;)
> А это уже программер сам как-нибудь должен в апликухе, если оно ему
> надо.

Разве это не зависит от архитектуры конкретной фс ?

> А тут уже одним сисколом не отвертишься, понадобится программа которая их дернет
> в произвольном порядке. В первом приближении таковым можно посчитать обычный dd
> которым вы так козыряли ;). Если за каким-то надо еще и
> дестроить то что он скопировал - ну, придется допатчить. Правда я
> не понимаю нафиг это надо, но...

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

Ответить | Правка | Наверх | Cообщить модератору

165. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +1 +/
Сообщение от Аноним (-), 29-Окт-12, 20:51 
> Разве это не зависит от архитектуры конкретной фс ?

А вот это и будет головняком программера апликухи - определить что и как в фиг знает какой ФС. Стандартных вызовов для этого вроде как нет. Я о таковых не в курсе во всяком случае.

>> не понимаю нафиг это надо, но...
> Нужно например удалить блок в середине файла, не удаляя сам файл.

Смотря что понимать под удалить.
1) Заменить содержимое другим, бесполезным для недругов: делается через seek в нужную позицию + write по размеру блока.
2) Если же хочется просто отдать место в файловую систему а там она пусть сама протирает это когда захочет - это и есть hole punching. Де-аллокация блока в середине файла. ФС может считать это незанятым местом и юзать как хочет.

Ответить | Правка | Наверх | Cообщить модератору

167. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от nagualemail (ok), 29-Окт-12, 20:53 
> Смотря что понимать под удалить.
> 1) Заменить содержимое другим, бесполезным для недругов: делается через seek в нужную
> позицию + write по размеру блока.
> 2) Если же хочется просто отдать место в файловую систему а там
> она пусть сама протирает это когда захочет - это и есть
> hole punching. Де-аллокация блока в середине файла. ФС может считать это
> незанятым местом и юзать как хочет.

Нужно уменьшить размер файла на длину удаляемого блока.

Ответить | Правка | Наверх | Cообщить модератору

179. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +1 +/
Сообщение от Аноним (-), 30-Окт-12, 00:35 
> Нужно уменьшить размер файла на длину удаляемого блока.

Поскольку это пересекается с sparse файлами, надеюсь что мсье в курсе что есть sparse и как получается что 100500Гб файл может занимать всего 10Мб на диске. Ну вот hole punch это инверсное действие. Занимаемое место сокращается, т.к. блоки отдаются ФС. А логический размер остается как и был. То-есть, если выкусили 5Мб, файловая система получит их назад и файл будет занимать по факту лишь 5Мб. Хотя логический размер в 100500Гб у него останется. Файл делается "более sparse".

Кстати posix_fallocate() так не умеет. Линевый fallocate() - расширенная версия, через которую можно posix_fallocate() забабахать в 2 счета, но у него есть как аллокация так и деаллокация. Что довольно логично. Просто POSIX ничего не знает о sparse файлах и сами по себе sparse являются следствием того что стандарт никак не обязывает ФС что-либо реально выделять под некий файл просто на основании того что его создали и возжелали чтобы это было нечто размером в 100500Гб. Файловая система имеет полное право выделять фактическое место как-нибудь потом и это ее внутренее дело. Если в сторону создания sparse-ов можно считерить не выехав за рамки posix, то вот с деаллокацией и разреживанием файлов так уже не получится. В posix тупо нет сисколлов через которые так можно сделать, ни с читерством ни без.

Если же речь была о том чтобы урезать и логический размер файла (при наличии sparse это довольно декларативная цифра и оно не так уж и актуально) - тогда да, придется вырубить блок и присобачить хвост файла его фактическим перемещением. Не потому что иначе запрещают законы физики и логики, а потому что в posix опять же IIRC нет каких либо сисколов для того чтобы внятно запросить данную операцию. Хотя чисто технически я вполне могу себе представить как какой-нибудь CoW вообще не будет кантовать при этом данные и оформит это как просто измененный вариант метаданных, описывающих размещение файла с поправкой на "выпавший" или "урезанный" блок. Да и обычный дизайн в принципе мог бы. Просто метаданные описывающие размещение придется перестраивать. Основная проблема в том что для такого нет рукояток. Видимо не столь частая операция чтобы кому-то понадобилось.

Ответить | Правка | Наверх | Cообщить модератору

180. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от nagualemail (ok), 30-Окт-12, 00:51 
>[оверквотинг удален]
> хвост файла его фактическим перемещением. Не потому что иначе запрещают законы
> физики и логики, а потому что в posix опять же IIRC
> нет каких либо сисколов для того чтобы внятно запросить данную операцию.
> Хотя чисто технически я вполне могу себе представить как какой-нибудь CoW
> вообще не будет кантовать при этом данные и оформит это как
> просто измененный вариант метаданных, описывающих размещение файла с поправкой на "выпавший"
> или "урезанный" блок. Да и обычный дизайн в принципе мог бы.
> Просто метаданные описывающие размещение придется перестраивать. Основная проблема в
> том что для такого нет рукояток. Видимо не столь частая операция
> чтобы кому-то понадобилось.

Для быстрого создания условий тестирования быстродейтсвия файловой системы в условиях максимальной фрагментации возможны два варианта - с одним файлом большим файлом и множеством мелких. Итак если с одним большим - осуществляем операции записи и чтения на тестируемый диск от 0% заполненности файлами до 100% и вычисляем средние скорости чтения и записи. Как только скорости чтения и записи перестануть падать, считаем фрагментацию максимальной а скорости результирующими для данной фс. На самом деле сложнее: Если пишем то пишем вставляя в середину файла с произвольным смещением от начала и произвольной длины блок. Если удаляем блок то не удаляем его совсем а вырезаем из середины с произвольным смещением и произвольной длиной и потом добавляем ео в конец. Назовите функции которые позволят это реализовать ?
Это нужно как минимум в бд и торрентах ...

Ответить | Правка | Наверх | Cообщить модератору

226. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +/
Сообщение от Аноним (-), 01-Ноя-12, 19:51 
> Для быстрого создания условий тестирования быстродейтсвия файловой системы в условиях
> максимальной фрагментации возможны два варианта -

Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.

> с одним файлом большим файлом и множеством мелких.

Это весьма разные варианты. В первом случае основная нагрузка - на поведение аллокатора и его способность выруливать в сложных ситуациях. Во втором - нагрузка на способности ФС интенсивно работать с метаданными, тогда как аллокатору особо не на чем надрываться.

> Итак если с одним большим - осуществляем операции записи и чтения на тестируемый
> диск от 0% заполненности файлами до 100% и вычисляем средние скорости чтения и записи.

В принципе это - вполне валидный бенч. Хоть и сферический в вакууме, но он может показать умения аллокатора ФС работать в сложных условиях. Кроме этого однако есть еще разница какими порциями и как файл дописывался. Влияет на объем метаданных описывающих размещение файла, etc.

И стоит учесть что разные ФС имеют разные свойства и CoW - based будут себя вести

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

ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с ним справится. А то сравнивать неодинаковый набор операций - это сравнение ежа с ужом. Из такого результата никаких особых выводов сделать не получится. Потому что в этом случае никак не учитывается способность ФС бороться с фрагментацией. Может, одна ФС чертовски фрагментируется за 5 минут, а другая за 2 дня издевательств. В реальном мире фрагментация ФС редко достигает максимума когда "хуже уже не будет", т.к. для этого нужны совсем запредельные условия и безбашенный админ. Бенч все-таки должен иметь какую-то практическую ценность.

> На самом деле сложнее: Если пишем то пишем вставляя в середину файла
> с произвольным смещением от начала и произвольной длины блок.

IIRC, в семантике POSIX )и большинстве иных похожих по смыслу), файлы умеют расти только с хвоста. Запись в середину перезаписывает то что там было, не раздвигая файл а переписывая содержимое. Увеличить размер можно лишь дописав в хвост. Просто потому что как обычным файловым системам было бы очень напряжно как-либо оформить "раздвигание" файла.

Для классики перезапись файла в середине - вообще ни о чем: оно от этого фрашментироваться не станет. Для CoW это может заставить ФС сорить фрагментами-выносками. В том числе и по этой причине CoW в чистом виде не ахти для баз данных. По поводу чего можно предсказать что на подобном тесте классики будут лучше себя ощущать. В этом месте приходит понимание нафига оракловый архитект предусмотрел возможное отключение CoW в btrfs. Оно сможет стать "как бы классикой" если это реально приспичило ;). Да, это лишает плюшек CoW но базам данных эти плюшки скорее вредны чем полезны, т.к. активно клещатся с их журналом и идеей атомарных транзакций.

> Если удаляем блок то не удаляем его совсем а вырезаем из середины с произвольным
> смещением и произвольной длиной и потом добавляем ео в конец.

Мсье, в posix-овской семантике (как и в большинстве иных) такое не предусмотрено. Там урезать размер файла можно только отбрасыванием его хвоста. Потому что операция "сдвигания" файлов не особо проста в реализации. Особенно в ФС эпохи когда POSIX только формировался.

> Назовите функции которые позволят это реализовать ?

Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.

> Это нужно как минимум в бд и торрентах ...

Там это делается не совсем так как вы описали. И кстати по этому поводу есть ряд ограничений. Например, файл базы данных при активной работе с БД растет со временем (если не преаллоцирован заранее с запасом, конечно). И даже если удалить половину записей в таблице - это еще совсем не означает что файл можно будет взять и уменьшить.

...в этом месте мы до кучи начинаем догадываться нафига в базах данных есть операция дефрагментации/vacuum/кто там как еще это действо у себя обзывает и почему БД уменьшаются только после этой операции как правило :). А торренты - они предмет простой. Получили блок - запись в файл по нужному смещению. А преаллокация - по сути выбор между тем что хвост будет отрастать "как получится" или файл заранее будет заказан на полный размер. при том quick преаллокация - это мягкий хинт для ФС что "а вот мы собираемся сделать файл такого размера", а full - фактическая запись файла и потом перезапись блоков по мере скачки. Для классики так лучше. CoW - скорее даже ухучшит картину.

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

233. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –1 +/
Сообщение от nagualemail (ok), 01-Ноя-12, 23:07 
>> Для быстрого создания условий тестирования быстродейтсвия файловой системы в условиях
>> максимальной фрагментации возможны два варианта -
> Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.

Мы не обсуждаем сферических коней в вакууме - пофиг как оно там внутри работает ...

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

Да и интересны оба.

>> Итак если с одним большим - осуществляем операции записи и чтения на тестируемый
>> диск от 0% заполненности файлами до 100% и вычисляем средние скорости чтения и записи.
> В принципе это - вполне валидный бенч. Хоть и сферический в вакууме,
> но он может показать умения аллокатора ФС работать в сложных условиях.
> Кроме этого однако есть еще разница какими порциями и как файл
> дописывался. Влияет на объем метаданных описывающих размещение файла, etc.

Реальный бенч, реальные файлы ничего в вакууме ...

> И стоит учесть что разные ФС имеют разные свойства и CoW -
> based будут себя вести

Проблемы индейцев нас не волнуют.

>> Как только скорости чтения и записи перестануть падать, считаем фрагментацию
>> максимальной а скорости результирующими для данной фс.
> ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с
> ним справится. А то сравнивать неодинаковый набор операций - это сравнение
> ежа с ужом. Из такого результата никаких особых выводов сделать не
> получится.

Месье не на выборах, подтасовать результаты на этапе поставновки задачи не получится.

>Потому что в этом случае никак не учитывается способность ФС
> бороться с фрагментацией
. Может, одна ФС чертовски фрагментируется за 5 минут,
> а другая за 2 дня издевательств.

Проблемы индейцев.

> В реальном мире фрагментация ФС
> редко достигает максимума когда "хуже уже не будет", т.к. для этого
> нужны совсем запредельные условия и безбашенный админ. Бенч все-таки должен иметь
> какую-то практическую ценность.

Ну мы та после изучения форумов знаем что для правильной эксплуотации ZFS нужно не первышать 65% заполнения. Имеет ли смысл тестировать вариант безбашенного админа ... сомневаюсь.

>> На самом деле сложнее: Если пишем то пишем вставляя в середину файла
>> с произвольным смещением от начала и произвольной длины блок.
> IIRC, в семантике POSIX )и большинстве иных похожих по смыслу), файлы умеют
> расти только с хвоста. Запись в середину перезаписывает то что там
> было, не раздвигая файл а переписывая содержимое. Увеличить размер можно лишь
> дописав в хвост. Просто потому что как обычным файловым системам было
> бы очень напряжно как-либо оформить "раздвигание" файла.

Шел 2012 год, большинство фс по прежнему неумело "раздвигание" файла. Из за этого реализовать вариант с фрагментацией одного файла можно только следующим путем - забить диск множеством мелких файлов и начать писать большой файл освобождая место путем стирания произвольного колличества мелких файлов. В результате большой файл будет фрагментирован и на его чтении можно будет хоть что то измерить ...

>> Если удаляем блок то не удаляем его совсем а вырезаем из середины с произвольным
>> смещением и произвольной длиной и потом добавляем ео в конец.
> Мсье, в posix-овской семантике (как и в большинстве иных) такое не предусмотрено.
> Там урезать размер файла можно только отбрасыванием его хвоста. Потому что
> операция "сдвигания" файлов не особо проста в реализации. Особенно в ФС
> эпохи когда POSIX только формировался.

Красота реализации POSIX удручает.

>> Назовите функции которые позволят это реализовать ?
> Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.

В Linux fallocate() и splice() насчет второго неуверен ... тоже самое насчет sendfile() будет время опробую.

>> Это нужно как минимум в бд и торрентах ...
> Там это делается не совсем так как вы описали. И кстати по
> этому поводу есть ряд ограничений. Например, файл базы данных при активной
> работе с БД растет со временем (если не преаллоцирован заранее с
> запасом, конечно). И даже если удалить половину записей в таблице -
> это еще совсем не означает что файл можно будет взять и
> уменьшить.

Оптимизация таблиц блокирует эти самые таблицы ? На плохо предсказуемое время ?

>[оверквотинг удален]
> есть операция дефрагментации/vacuum/кто там как еще это действо у себя обзывает
> и почему БД уменьшаются только после этой операции как правило :).
> А торренты - они предмет простой. Получили блок - запись в
> файл по нужному смещению. А преаллокация - по сути выбор между
> тем что хвост будет отрастать "как получится" или файл заранее будет
> заказан на полный размер. при том quick преаллокация - это мягкий
> хинт для ФС что "а вот мы собираемся сделать файл такого
> размера", а full - фактическая запись файла и потом перезапись блоков
> по мере скачки. Для классики так лучше. CoW - скорее даже
> ухучшит картину.

В винде торрент так и делает - выделяет место на порлный размер. Голь на выдумки хитра.


Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

302. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +1 +/
Сообщение от Аноним (-), 05-Ноя-12, 08:48 
>> Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.
> Мы не обсуждаем сферических коней в вакууме - пофиг как оно там внутри работает ...

В данном случае не пофиг, имхо. Одно дело если 100500Мб файл занимает по факту 10Мб потому что в него только 10Мб записали и совсем другая картина если под него честно выкроены 100500Мб. Очень разные ситуации получатся.

>> нагрузка на способности ФС интенсивно работать с метаданными, тогда как аллокатору
>> особо не на чем надрываться.
> Да и интересны оба.

Да. Только это совершенно отдельные бенчи по логике вещей. Один - "скорость операций с большим файлом". Второе - скорость работы с метаданными на мелочи. Еще возможен вариант "фантомас в очках на аэроплане" - когда большой файл специально состоит из кучи фрагментов. Как большой торрент (много больше дисковых буфферов ОС) без преаллокации, например. В этом случае ФС как правило не сможет очень уж сильно линеаризовать запись и поневоле сгенерит дофига метаданных описывающих размещение файла. Так можно создать ощутимые проблемы даже XFS, который на более простые методы фрагментации не особо то и покупается.

> Реальный бенч, реальные файлы ничего в вакууме ...

Реальный бенч пытается быть похожим на какие-то нагрузки встречающиеся в реальном мире. Случай когда скорость ФС упала до минимально возможной мало кого устраивает и в таком виде ФС мало кто эксплуатирует. Ну то-есть я знаю пока целого 1 кадра которого устраивает 6Мб/сек со шпинделя. Это наверное еще не минимум. Но вполне удачная попытка к нему приблизиться :)

>> И стоит учесть что разные ФС имеют разные свойства и CoW - based будут себя вести
> Проблемы индейцев нас не волнуют.

Просто у разных дизайнов заведомо разные свойства. У самолетов одни проблемы, у автомобилей другие. Недостатком автомобилей и самолетов это не является.

>> ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с
>> ним справится. А то сравнивать неодинаковый набор операций - это сравнение
>> ежа с ужом. Из такого результата никаких особых выводов сделать не получится.
> Месье не на выборах, подтасовать результаты на этапе поставновки задачи не получится.

Так это не подтасовка. Это попытка имитировать реальную эксплуатацию. Чудаков типа изена в природе немного, остальные предпочитают получать от ФСов более разумные параметры по ходу эксплуатации ;). Краевые ситуации в принципе тоже могут представлять интерес, но как некий отдельный случай. С изучением насколько сложно в него попасть и прочая.

>> а другая за 2 дня издевательств.
> Проблемы индейцев.

Не индейцев а пользователей ФС. Задача бенча - не полить кого-то грязью или выпятить вперед/назад, а смоделировать типовые варианты эксплуатации, чтобы по результатам бенча можно было хотя-бы грубо прикинуть как ФС себя поведет в вот этом вот случае и надо ли ее такую хорошую брать под эту задачу или лучше обойти сторонкой в пользу чего-нибудь еще.

> Ну мы та после изучения форумов знаем что для правильной эксплуотации ZFS
> нужно не первышать 65% заполнения. Имеет ли смысл тестировать вариант безбашенного
> админа ... сомневаюсь.

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

>> дописав в хвост. Просто потому что как обычным файловым системам было
>> бы очень напряжно как-либо оформить "раздвигание" файла.
> Шел 2012 год, большинство фс по прежнему неумело "раздвигание" файла.

Како-то так вышло что почти все легковые автомобили как правило 4-колесные. Хотя могли бы быть и с другим количеством колес. Ну вот такой вот дизайн устоялся. А могли бы и турбореактивный двигатель привинтить. И крылья. Было бы круче. Но видимо столько счастья ALLу не надо было и спрос на фичу не сформировался.

> Из за этого реализовать вариант с фрагментацией одного файла можно только
> следующим путем - забить диск множеством мелких файлов и начать писать большой файл

Мсье как обычно забыл что для CoW и обычных ФС все будет по разному.

Hint1: на очень сильно фрагментированной ФС скорость доступа будет близка к тому что дает "random seeking" с мелкими блоками. Результат будет сильнее всего зависеть от seek time накопителя и размера запрашиваемого блока: чем хуже соотношение чтения блока к перемещению голов, тем хреновее результат. Этот эффект можно понаблюдать вообще без ФС - просто доступ к накопителю как RAW девайсу и чтение секторов там и тут даст то же самое. По поводу чего не очень понятно что даст указанный тест. Он будет не столько параметры ФС тестировать сколько свойства накопителя. Вот у изена с его ноутбучным винчом все особенно плохо: seek time у ноутбучных накопителей паршивый. На десктопном и шустром - было бы порезвее немного.

Хинт2: для "классики" совершенно нормально прилагать максимум усилий для раскладывания файла как можно более линейно (успешность этого начинания зависит от реализации аллокатора). CoW так не может из-за принципа работы. Если запись в середину файла в классике не создаст новый фрагмент и дозапись по возможности будет отращивать хвост дальше без фрагментации (покуда там свободное место есть) то CoW при записи в середину файла неизбежно сделает выносок-фрагмент в сторону.

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

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

>> эпохи когда POSIX только формировался.
> Красота реализации POSIX удручает.

Другие API (например WinAPI) похожи в этом плане. Ну как почти все автомобили с 4 колесами, рулем и так далее, так и эти API все более-менее похожи.

>>> Назовите функции которые позволят это реализовать ?
>> Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.
> В Linux fallocate() и splice() насчет второго неуверен ... тоже самое насчет
> sendfile() будет время опробую.

Не совсем понял при чем тут splice и sendfile. Они конечно хороши тем что меньше грузят систему т.к. нет копирования памяти между юзермодом и ядром, но принципы работы с файлами они не меняют. А fallocate интересен только тем что там сделали операцию обратную превращению sparse файла в обычный. Хоть это и не входит в posix (который о sparse файлах вообще не в курсе) и довольно нишевая хрень.

>> это еще совсем не означает что файл можно будет взять и уменьшить.
> Оптимизация таблиц блокирует эти самые таблицы ? На плохо предсказуемое время ?

Я не о том. Чтобы уменьшить размер файла базы мне известна буквально пара вариантов. Первый - это расчистить хвост, затолкав данные оттуда в свободные страницы в начале файла. Т.е. обычная дефрагментация "объединение свободного места в хвост" + стандартное откусывание хвоста. Второй вариант - полная перестройка нового файла на основе старого но без прорех + стирание старого файла с прорехами. По смыслу одно и то же, только по разному. В случае fallocate() с возможностью разреживания - сделали хитрый финт ушами и прикрутили возможность метить регионы файла как "опять пустые".

>> по мере скачки. Для классики так лучше. CoW - скорее даже ухучшит картину.
> В винде торрент так и делает - выделяет место на порлный размер.

Внезапно, торрент-клиенты так делают не только в винде. Например у того же transmission (который сложно отнести к виндовым) есть 2 режима преаллокации файлов, быстрый и полный. Первый лишь декларирует в сторону ФС что у нас дескать есть намерения получить файл такого размера (sparse как раз об этом). Дальше ФС сама по мере возможности пхает скачанные блоки как получится и как позволяет ситуация. В идеальном случае - может разложить хорошо. Но если качается 100500 файлов параллельно и прочая - может выйти и не совсем оптимально. Второй режим реально заполняет файл по всему объему при его создании и потом по мере скачки блоков просто переписывает регионы файла. На классике это приводит к тому что блоки кладутся в заранее подготовленное "русло" и лежат так, по поводу чего оно максимально линейно насколько ФС в принципе могла это сделать в той ситуации. На CoW такое однако имхо ни к чему хорошему не приведет. Это оптимизация которая хороша для классических дизайнов.

> Голь на выдумки хитра.

Да в общем то общеизвестные техники и каждый первый уважающий себя торрент клиент это так или иначе умеет, кроме совсем уж простейших. Просто в некоторых надо ман почитать еще.

Ответить | Правка | К родителю #233 | Наверх | Cообщить модератору

364. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –1 +/
Сообщение от nagualemail (ok), 06-Ноя-12, 01:30 
> даже XFS, который на более простые методы фрагментации не особо то
> и покупается.

Проблемы индейцев.

>> Реальный бенч, реальные файлы ничего в вакууме ...
> Реальный бенч пытается быть похожим на какие-то нагрузки встречающиеся в реальном мире.
> Случай когда скорость ФС упала до минимально возможной мало кого устраивает
> и в таком виде ФС мало кто эксплуатирует. Ну то-есть я
> знаю пока целого 1 кадра которого устраивает 6Мб/сек со шпинделя. Это
> наверное еще не минимум. Но вполне удачная попытка к нему приблизиться
> :)

Вам же сказали "Реальный бенч, реальные файлы" а вы опять со своимы конями в вакуме.

> Просто у разных дизайнов заведомо разные свойства. У самолетов одни проблемы, у
> автомобилей другие. Недостатком автомобилей и самолетов это не является.

Тесты покажут у кого какие проблемы.

> Так это не подтасовка. Это попытка имитировать реальную эксплуатацию. Чудаков типа изена
> в природе немного, остальные предпочитают получать от ФСов более разумные параметры
> по ходу эксплуатации ;). Краевые ситуации в принципе тоже могут представлять
> интерес, но как некий отдельный случай. С изучением насколько сложно в
> него попасть и прочая.

Друг мой вы случайно не из партіi ВО "Батьківщина" ? Еще раз - вы не на выборах подтасовать условия тестирования не получится.


> Не индейцев а пользователей ФС. Задача бенча - не полить кого-то грязью
> или выпятить вперед/назад, а смоделировать типовые варианты эксплуатации, чтобы по результатам
> бенча можно было хотя-бы грубо прикинуть как ФС себя поведет в
> вот этом вот случае и надо ли ее такую хорошую брать
> под эту задачу или лучше обойти сторонкой в пользу чего-нибудь еще.

В двух словах индейцы в панике.

> То только что утверждал что это проблемы индейцев, то теперь вдруг сам
> согласен что случай безбашенной эксплуатации рассматривать странно. Неплохо бы определиться
> :)

Наш большой файл в сумме с мелкими не будет занимать более 65% фс.


> Како-то так вышло что почти все легковые автомобили как правило 4-колесные. Хотя
> могли бы быть и с другим количеством колес. Ну вот такой
> вот дизайн устоялся. А могли бы и турбореактивный двигатель привинтить. И
> крылья. Было бы круче. Но видимо столько счастья ALLу не надо
> было и спрос на фичу не сформировался.

Вы явно не в теме, если бы не сомнительные личности из нефтегазового сектора мы бы на стат поясах летали бы ...


> Hint1: на очень сильно фрагментированной ФС скорость доступа будет близка к тому
> что дает "random seeking" с мелкими блоками. Результат будет сильнее всего
> зависеть от seek time накопителя и размера запрашиваемого блока: чем хуже
> соотношение чтения блока к перемещению голов, тем хреновее результат.

Вот имеено этот тест хочется проделать на диске в памяти :))

>Этот эффект
> можно понаблюдать вообще без ФС - просто доступ к накопителю как
> RAW девайсу и чтение секторов там и тут даст то же
> самое. По поводу чего не очень понятно что даст указанный тест.
> Он будет не столько параметры ФС тестировать сколько свойства накопителя. Вот
> у изена с его ноутбучным винчом все особенно плохо: seek time
> у ноутбучных накопителей паршивый. На десктопном и шустром - было бы
> порезвее немного.

Я вижу вы неравнодушны к Изену :))

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

Прежде всего я ожидаю увидеть как не все участники тестирования придут к финишу :)) вероятно завалит тест btrfs :))

> Другие API (например WinAPI) похожи в этом плане. Ну как почти все
> автомобили с 4 колесами, рулем и так далее, так и эти
> API все более-менее похожи.

Копипаст во всей красе :)) Последствия bsd лицензии :)))

> Не совсем понял при чем тут splice и sendfile. Они конечно хороши
> тем что меньше грузят систему т.к. нет копирования памяти между юзермодом
> и ядром, но принципы работы с файлами они не меняют. А
> fallocate интересен только тем что там сделали операцию обратную превращению sparse
> файла в обычный. Хоть это и не входит в posix (который
> о sparse файлах вообще не в курсе) и довольно нишевая хрень.

Так есть возможность реализовать или таки нет :))) Напоминаю шел 2012 год ...


> Я не о том. Чтобы уменьшить размер файла базы мне известна буквально
> пара вариантов. Первый - это расчистить хвост, затолкав данные оттуда в
> свободные страницы в начале файла. Т.е. обычная дефрагментация "объединение свободного
> места в хвост" + стандартное откусывание хвоста. Второй вариант - полная
> перестройка нового файла на основе старого но без прорех + стирание
> старого файла с прорехами. По смыслу одно и то же, только
> по разному. В случае fallocate() с возможностью разреживания - сделали хитрый
> финт ушами и прикрутили возможность метить регионы файла как "опять пустые".

И какой из этих вариантов рабочий при условии что начальный и конечный файлы занимают больше чем 50% диска ? :)))

Ответить | Правка | К родителю #302 | Наверх | Cообщить модератору

365. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  +2 +/
Сообщение от AlexAT (ok), 06-Ноя-12, 07:17 
>> Просто у разных дизайнов заведомо разные свойства. У самолетов одни проблемы, у
>> автомобилей другие. Недостатком автомобилей и самолетов это не является.
> Тесты покажут у кого какие проблемы.

Тесты Lamborghini на проселочной дороге или Запорожца на автобане? xD

> Друг мой вы случайно не из партіi ВО "Батьківщина" ? Еще раз
> - вы не на выборах подтасовать условия тестирования не получится.

Переклинило на выборах?

> Наш большой файл в сумме с мелкими не будет занимать более 65%
> фс.

"> Вам же сказали "Реальный бенч, реальные файлы" а вы опять со своимы
> конями в вакуме."
> Вы явно не в теме, если бы не сомнительные личности из нефтегазового
> сектора мы бы на стат поясах летали бы ...

И на мётлах.

> Вот имеено этот тест хочется проделать на диске в памяти :))

Странная эротическая фантазия. Вам же сказали - реальный бенч...

> Прежде всего я ожидаю увидеть как не все участники тестирования придут к
> финишу :)) вероятно завалит тест btrfs :))

Цели "теста" уже ясны, далее можно не продолжать.

> И какой из этих вариантов рабочий при условии что начальный и конечный
> файлы занимают больше чем 50% диска ? :)))

"> Вам же сказали "Реальный бенч, реальные файлы" а вы опять со своимы
> конями в вакуме."

Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

366. "Теодор Тцо отказался от предложений по стабилизации ФС Ext4 ..."  –2 +/
Сообщение от nagualemail (ok), 06-Ноя-12, 12:23 
> Тесты Lamborghini на проселочной дороге или Запорожца на автобане? xD

Если вытак уверены в победе зачем так беспокоиться ? :)))

> Переклинило на выборах?

Не, задолбали упоротые фанатики.

> И на мётлах.

Может быть ...

> Странная эротическая фантазия. Вам же сказали - реальный бенч...

И вы тоже в темноте под одеялом ? Свободнаю рукою ? :))

> Цели "теста" уже ясны, далее можно не продолжать.

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

Ответить | Правка | К родителю #365 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру