29295 ответов в теме

[Karmael]

шпитфоер не нашел знакомых слов и снова порвался. опять

[r0n1]

Можно диагностировать:
Некрософт так и не научился работать с собственной фс, но перестала падать.
Прогресс как ни крути.

ну как бы если верить тому что пишет Ali On некросовт выньдос работает с собственной фс лучше чем лин команды с ext

просто ты не смог в нтфс, а виноват некрософт.

[Karmael]

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

Ну и во вторых, это конечно очень занимательно ловкими маневрами обходить опрос ФС, но тем не менее не тестирует саму фс, от этого и хочется смотреть в творчество, а творчество не показывают

[Ali On]

Ну, поехали.

Код - говнище, так писать нельзя, сразу говорю. На коленке, через гугл писалось.

То, чем сгенерил прямо в зип - неинтересно, очевидно.

То чем паковал 1.4кк живых файлов - под катом

Спойлер

import zipfile
import os
import time


os.chdir('e:\\1_5kk')
z = zipfile.ZipFile('e:\zxc_pack_real_shit.zip', "w")
start_time = time.time()
number = 0;
for entry in os.scandir('.\\'):
    number += 1
    print (f"\rFile number {number:{12}}, name {entry.name}", end='')
    z.write(entry.path)
z.close()
running_time = time.time() - start_time
speed = number * 1.0/running_time
print(f"\nDone: {number} files in {running_time} seconds. Speed: {speed}")

 

 

1й раз распаковывал тем, что в инсталляции гита под винду шло. Напомню. На 1.3кк он мог примерно в 3 файла в секунду уже.

Спойлер

$ unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

к слову, о "вечных" программах - 2009. Есть вероятность, что он через очень уж высокие абстракции с нтфс работает. Можно было бы быстрее чем-то другим.

 

То, чем сейчас распаковывается это под этим катом (всё ещё вертится, 700к файлов распаковано)

Спойлер

import zipfile
import os
import time

os.chdir('e:\\1_5kk')
z = zipfile.ZipFile('e:\zxc_pack_real_shit.zip', "r")
start_time = time.time()
number = len(z.namelist())
print (f"\nFiles in zip: {number}")
z.extractall('e:\\1_5kk')
z.close()
running_time = time.time() - start_time
speed = number * 1.0/running_time
print(f"\nDone: {number} files in {running_time} seconds. Speed: {speed}")

 

То чем собираюсь удалять, чтобы сравнить с экплорером (он с 700 вышел на 500 файлов в секунду, после опредлённой точки. Причём прервать удаление и начать снова через короткий промежуток времени уже никак не влияло. Или кеш нагнуло, или по диску раскидало, я хз)

Спойлер

import zipfile
import os
import time


os.chdir('e:\\1_5kk')
start_time = time.time()
number = 0;
for entry in os.scandir('.\\'):
    number += 1
    t_time = time.time() - start_time
    speed = number * 1.0 / t_time
    print(f"\rSpeed {speed:{12}.{3}} File number {number:{12}}, name {entry.name}", end='')
    os.remove(entry.name)
running_time = time.time() - start_time
speed = number * 1.0/running_time
print(f"\nDone: {number} files in {running_time} seconds. Speed: {speed}")

 

 

Вполне очевидно, что фс не принимала участие только в нулевом варианте, когда я сгенерил 1.5кк прямиком в зип.

Эксплорер вполне справляется с верчением этой папки вдоль и поперёк без падений. Но медленно, да.

нативный dir из cmd бодро листает всё содержимое

ls из тех же гитовых приблуд только с парой ключей показывать начинает что-то адекватное.

 

ps Карма, вот если бы ты скайп включал почаще, давно бы уже всё обсудили

 

upd: да, я посмотрел как extractall работает у ZipFile питона - он сначала дёргает весь список файлов в архиве и потом уже извлекает по одному.

 

upd2: в распаковке из питона стоило взять этот список и самому дёргать, конечно, чтобы видеть деградацию по скорости, если такая есть/будет. Пока 900к

Сообщение отредактировал Ali On: 03 October 2018 - 16:47

[Karmael]

Добротно для коленочного теста, одобряю

только я так и не понял, ты файлы то генерил пустые? 

из продемонстрированного кода сие не ясно просто 

[Ali On]

Только сейчас заметил, что 3й скрипт не тот вставлен и отступы съехали. А это же питон, мать его. Поправил.

 

Не пустые, с заполнением минимальным

 

Использовал что-то типа

Спойлер

import zipfile
import os
import time


os.chdir('e:\\')
z = zipfile.ZipFile('e:\zxc_sample.zip', "w")
start_time = time.time()
number = 0;
for i in range(100000):
    number += 1
    name = f"file_sample_{i}"
    print (f"\rFile number {number:{12}}, name {name}", end='')
    z.writestr(name, (f"254235rew____{i:{10}}"))
z.close()
running_time = time.time() - start_time
speed = number * 1.0/running_time
print(f"\nDone: {number} files in {running_time} seconds. Speed: {speed}")

 

 

на 100к

 

File number       100000, name file_sample_99999
Done: 100000 files in 5.954595327377319 seconds. Speed: 16793.75247218431

Process finished with exit code 0

 

 

upd: сильное падение скорости распаковки после 1+кк примерно. Наблюдаю такую же херню с питоновским анзипом сейчас. Похоже, используют одно и то же отверстие в функциях оси. Но глубже копаться не буду уже. Подожду пока распакует, потом удалялку запущу для сравнения с эксплорером.

Сообщение отредактировал Ali On: 03 October 2018 - 17:03

[Xiemargl]

Загоняюсь чё-то, да, по числам.Ещё раз повторю, паровозик смог затащить и посчитать все файлики в папочке. Зря, конечно, но его заставили ))

На данный момент упаковано 1.2кк реальных фалов. Генерить быстрее, конечно. Скорость не падает, кстати.

dak1976gv  Винда тащит пока что. Падать упорно не хочет.

Надо подобный "экскремент" с опенсорсом провести. Надеюсь, кто нибудь сделает.

 

зы мне как бы насрать кто там упадёт/не упадёт. Сижу я под виндой, пишу на жабке, деплоюсь куда попало, но, в основном, линупсы всякие. Так что толерантность к операционкам высокая.

 

update:

C:\ProgramData\Anaconda3\python.exe E:/oops/ads.py
File number      1394262, name file_999999.wow
Done: 1394262 files in 2753.564329147339 seconds. Speed: 506.34807592519303

Process finished with exit code 0

 

update 2: решил удалить через del в cmd. Подождал минут 5, выключил, сожрало 300к. Решил эксплорером - тот сделал списочек на оставшиеся 1.1кк, переспросил, а уверен ли я, что хочу все эти 1.1 удалить и начал трудиться. Вышел на стабильные 700 файлов в секунду и работает. Сожрал одно ядро на i5

изучи команду >del .

вы это. как закончите - выкатите итоговое резюме для широкой обсчественности(которой в общем то лень вчитываться в весь этот чатик последних страниц)... кармарэйд или не_кармарейд?

ntfs не сломалась, сломался Карма 

[Karmael]

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

[Naimas Alvares]

Вообще изначально вопрос (с подачи Маркелова) был в том, что станет бутылочным горлышком раньше, скорость диска или фс/сопутствующее.

[Xiemargl]

....

1й раз распаковывал тем, что в инсталляции гита под винду шло. Напомню. На 1.3кк он мог примерно в 3 файла в секунду уже.

Спойлер

$ unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

к слову, о "вечных" программах - 2009. Есть вероятность, что он через очень уж высокие абстракции с нтфс работает. Можно было бы быстрее чем-то другим.

....

unzip работает через стандартные c-функции (+немного stat() для атрибутов), только списки по вилдкардам генерит сам

я его портировал, код весь перечитал

 

для полноты картины, МС еще выкатила серверную ReFS - но я не тестил

Сообщение отредактировал Xiemargl: 03 October 2018 - 17:30

[Ali On]

изучи команду >del .

 

Я там не вижу каких-то скрытых/хитрых параметров для ускорения процесса. Разве что вайлдкард заменить на директорию. Попробовать можно, но не уверен. Такое работало на фат32/16, вроде бы, что хватало удалить корневой элемент (директорию), даже не удалить, а флаг поставить, фактически. Но утверждать не буду. Давно было.

 

По анзипу понял. Как и подозревал, спасибо.

[Xiemargl]

Я там не вижу каких-то скрытых/хитрых параметров для ускорения процесса. Разве что вайлдкард заменить на директорию. Попробовать можно, но не уверен. Такое работало на фат32/16, вроде бы, что хватало удалить корневой элемент (директорию), даже не удалить, а флаг поставить, фактически. Но утверждать не буду. Давно было.

 

По анзипу понял. Как и подозревал, спасибо.

дель точка удаляет из текущего каталога. быстро, не листая файлы, но без субдиректорий

[Ali On]

дель точка удаляет из текущего каталога. быстро, не листая файлы, но без субдиректорий

Т. е. удаление каталога ( . - текущий же.) вместо удаления по списку. Угу.

[Karmael]

Что значит не листая файлы? Мне смеяться или плакать уже?

Опередун, зачем? Я бы послушал про листание

[Xiemargl]

а все dir, ls, rm, cp, mv, и прочие работают именно так, потому и падают. файнд не падает потому что списочек маленькый. но если искать все тоже упадет. 

причем честный только один zsh он собсвенно про это прямо и пишет, но у него совсем коротенький, и ломается уже на > 100к

....

вот листание == формирование списка файлов перед обработкой

 

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

 

тем более спор, не какой шелл хуже сделан, а ты наехал на ФС, которая по большинству параметров уделывает все Ексты

Сообщение отредактировал Xiemargl: 03 October 2018 - 17:45

[Karmael]

Это все делают через жопу

И не зависит от шела на прямую

[Ali On]

Вообще изначально вопрос (с подачи Маркелова) был в том, что станет бутылочным горлышком раньше, скорость диска или фс/сопутствующее.

Судя по тому, что я наблюдаю у себя сейчас, упираемся в фс сходу. Потому что писать подряд в один файл он может на 16к объектах в секунду, а вот даже читать/создавать именно с фс, ане из контейнера на фс - сразу где-то в 1к упираюсь со старта, после 1кк - дикая деградация.

Сообщение отредактировал Ali On: 03 October 2018 - 17:48

[Karmael]

Просто есть те кто написал эксепшен, и мы теперь знаем правду, а есть те кто тихонечко крашится

[Xiemargl]

Судя по тому, что я наблюдаю у себя сейчас, упираемся в фс сходу. Потому что писать подряд в один файл он может на 16к объектах в секунду, а вот даже читать/создавать именно с фс, ане из контейнера на фс - сразу где-то в 1к упираюсь со старта, после 1кк - дикая деградация.

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

 

в этом беда, и выбора ФС нет (

 

в лин есть хоть JFS и Reiser для такой нагрузки