The OpenNET Project / Index page

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



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

Оглавление

Раздел полезных советов: Решение проблем с удалением файлов ..., auto_tips (??), 01-Сен-09, (0) [смотреть все]

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


21. "Решение проблем с удалением файлов гигантского размера в Linux"  +/
Сообщение от Filosofemail (?), 01-Сен-09, 20:01 
exFat поддерживает до 2х ексабайт - разделы -:)))))
кажется так они хвастались. Правда как он посмотрит на 7ТБ  файл мне действительно
интересно

Автору - незачёт. Тема не разкрыта.
В коментах вижу более интересные решения.
Зающие товарищи, подпишите пожалуйста, кто из них работает?

XFS -это кончено хорошо, и мне нравится. Но формтить ради операции удаления... Вы простите.

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

23. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Pilat (ok), 01-Сен-09, 20:54 
>Автору - незачёт. Тема не разкрыта.

как раз раскрыта, решение найдено. В коментах другого проверенного нет.

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

24. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от pavlinux (ok), 01-Сен-09, 23:50 
Ни куя не раскрыто

http://i007.radikal.ru/0909/30/86b5c9a798b6.png


80Gb за 3 сек., это на буке с 5400 rpm винтом, 25Mb свободной оператифки.

7терабаб должны за ~300 сек. удалится, думается будет быстрее.

Что-то у чувачка хренова с настройками РЭЙД/ядра/прокладки ....

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

26. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Pilat (ok), 02-Сен-09, 00:18 
>80Gb за 3 сек., это на буке с 5400 rpm винтом, 25Mb
>свободной оператифки.
>
>7терабаб должны за ~300 сек. удалится, думается будет быстрее.
>
>Что-то у чувачка хренова с настройками РЭЙД/ядра/прокладки ....

7 терабайт фигурирует в сообщении, а не 7 гигабайт и не 70 гигабайт, это совершенно разные вещи и из удаления 80-гигабайтного файла никаких выводов сделать нельзя.

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

30. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от pavlinux (ok), 02-Сен-09, 01:28 
Да ну?! Доказательства в студию?

Скорость винта? Щаз. При 5400 это примерно

# dd if=/dev/urandom of=/TEST count=10 bs=10000k
10+0 записей считано
10+0 записей написано
скопировано 102400000 байт (102 MB), 16,8704 c, 6,1 MB/c

6 mb/s - это 80 Гб за 13400 сек.(~4 часа).

-------
Не уж-то все 80 Гб в ОЗУ влезли и оттуда удалились???
3 Гига, и пипец...


Да, 80Гб не 7 Тб, но оба размера гораздо больше всевозможных кэшей, аптимизилок, LARGEFILE64, PAE, итп...

Так что я убежден что оно пойдет линейно, а именно за 300 сек. исчезнет, 7Тб.


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

31. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Pilat (ok), 02-Сен-09, 01:32 
>Да ну?! Доказательства в студию?

Человек привёл доказательство в первом же посте. Можно ему верить, можно не верить, но аргументировать своё недоверие некорректно проведённым тестом нельзя.

Как аргумент в защиту ТС: http://inf.by/linux/?tgid=4204

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

49. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от pavlinux (ok), 02-Сен-09, 17:05 
>>Да ну?! Доказательства в студию?
>
>Человек привёл доказательство в первом же посте. Можно ему верить, можно не верить

Я ему верю, в том что них..я не работает, но не в том, что виновата ext4

Он это вывел методом исключения, учёл почти всё кроме самодельной сборки ядра 2.6.30.5,
на сколько мне известно, ни в одном дистрибутиве его ещё нет!



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

32. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от Karbofos (??), 02-Сен-09, 01:37 
да можно даже создать табличку зависимостей скорости удаления от размера файла. ;) ежели человек не верит. только в реале еще может быть куча трансакций к этому винчестеру, отчего io wait может прыгнуть вверх.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

41. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от iZEN (ok), 02-Сен-09, 09:34 
>Да ну?! Доказательства в студию?
>
>Скорость винта? Щаз. При 5400 это примерно
>
># dd if=/dev/urandom of=/TEST count=10 bs=10000k
>10+0 записей считано
>10+0 записей написано
> скопировано 102400000 байт (102 MB), 16,8704 c, 6,1 MB/c
>
>6 mb/s - это 80 Гб за 13400 сек.(~4 часа).

50МБ/сек на ноутбучном Western Digital серии Scorpio Blue (WD3200BEVT, 320 ГБ; SATA 3 Гб/с; Кэш 8 МБ; 5400 об/мин):

% dd if=/dev/zero of=/dev/ad10p3 bs=100m
dd: /dev/ad10p3: short write on character device
dd: /dev/ad10p3: end of device
3032+0 records in
3031+1 records out
317921280000 bytes transferred in 5836.782166 secs (54468587 bytes/sec)


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

69. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от John Lepikhin (ok), 03-Сен-09, 08:23 
1. Как минимум, странно мерить скорость винта, читая из медленного /dev/urandom. Читайте из /dev/zero.
2. Не надо мерить скорость винта, записывая файлик 100MB размером. Либо выключите write-cache, либо пишите в несколько раз больше, чем есть оперативки.
3. Нет линейной зависимости между размером файла и скоростью его удаления. И размер файла — далеко не единственный фактор, влияющий на это. В особенности при удалении с раздела, находящегося на программном рейде.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

40. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от iZEN (ok), 02-Сен-09, 09:28 
>exFat поддерживает до 2х ексабайт - разделы -:)))))
>кажется так они хвастались. Правда как он посмотрит на 7ТБ  файл
>мне действительно
>интересно
>
>Автору - незачёт. Тема не разкрыта.
>В коментах вижу более интересные решения.
>Зающие товарищи, подпишите пожалуйста, кто из них работает?

Готов лично протестировать массив на 10ТБ с ZFSv13 при условии предоставления жёстких дисков, блока питания и двух 4-х портовых PCI(PCI-E)-контроллёров для SAS/SATA-интерфейсов HDD.

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

50. "Решение проблем с удалением файлов гигантского размера в Lin..."  +/
Сообщение от pavlinux (ok), 02-Сен-09, 17:17 
>[оверквотинг удален]
>>мне действительно
>>интересно
>> Автору - незачёт. Тема не разкрыта.
>> В коментах вижу более интересные решения.
>> Зающие товарищи, подпишите пожалуйста, кто из них работает?
> Готов лично протестировать массив на 10ТБ с ZFSv13 при условии предоставления жёстких
> дисков, блока питания и двух 4-х портовых PCI(PCI-E)-контроллёров для SAS/SATA-интерфейсов
> HDD.

Купи, потесть, и расскажи другим.

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

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

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




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

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