Offtop

Уважаемый AP, очень хочу услышать твоё компетентное мнение здесь.

>>> а потом запилить например на ланчпад

Не надо на эту помойку, к тому же оно уже на гитхабе, если ты не заметил

Мнение арчефила я не спрашивал.И да,приглашаю во френды.

Омг, да у тебя болезнь уже. При чем здесь арч, скажи мне, если ланчпад действительно нафиг не нужен, когда исходники уже на гитхабе?

> Уже установлена самая новая версия linux-libc-dev

в треде советуют заменить в Makefile clang++ на g++

> круто. Можно даже новостью оформить

В этом нет смысла.

Как ни странно, но http://paste.org/pastebin/view/36375

splinter@sprogrammer:~/src/defrag/fragview$ make
clang++ -g3 -ggdb3 -O2 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12    -o graph.o -c graph.cpp
In file included from graph.cpp:4:
In file included from ./gtk_fragmap.h:3:
./clusters.h:8:8: error: unknown type name '__u64'
inline __u64 minu64(__u64 a, __u64 b) {
       ^
./clusters.h:8:1: error: 'inline' can only appear on functions
inline __u64 minu64(__u64 a, __u64 b) {
^
./clusters.h:8:21: error: use of undeclared identifier '__u64'
inline __u64 minu64(__u64 a, __u64 b) {
                    ^
./clusters.h:8:38: error: expected ';' after top level declarator
inline __u64 minu64(__u64 a, __u64 b) {
                                     ^
                                     ;
./clusters.h:20:21: error: use of undeclared identifier 'tuple'
typedef std::vector<tuple> tuple_list;
                    ^
./clusters.h:44:1: error: unknown type name '__u64'
__u64 get_device_size_in_blocks(const char *initial_dir);
^
./clusters.h:45:40: error: unknown type name '__u64'
void __fill_clusters(file_list *files, __u64 device_size_in_blocks, 
                                       ^
./clusters.h:46:30: error: unknown type name '__u64'
                                        cluster_list *clusters, __u64 cluster_count,
                                                                ^
In file included from graph.cpp:4:
./gtk_fragmap.h:25:2: error: unknown type name '__u64'
        __u64 device_size_in_blocks;
        ^
./gtk_fragmap.h:63:55: error: unknown type name '__u64'
void gtk_fragmap_set_device_size(GtkFragmap *fragmap, __u64 sib);
                                                      ^
10 errors generated.
make: *** [graph.o] Ошибка 1

Шо за нах?

Странно, linux/fs.h для определения __u64 должно быть достаточно, и на 32 и на 64-битных системах.

А что

grep -R 'typedef.*_u64;' /usr/include/

> В этом нет смысла.

а что, есть аналоги?

попробуй добавить в файлы, которые вызывают ошибки:

#include <linux/types.h>

> а что, есть аналоги?

Есть. Например, http://sourceforge.net/projects/davl/ .

Собралось

хотеть reiserfs

> хотеть reiserfs

без патча никак - программа использует только FIEMAP.

FIBMAP не сделал, да и ужасно медленно через FIBMAP.

https://github.com/i-rinat/fragview/blob/master/kernel-patches/reiserfs_fiema...

ой не - так не хочется совсем

> ой не - так не хочется совсем

А в чём проблема? Патч-то тривиальный.

ну уж нет
только ради этого лезть в код фс...
нафиг-нафиг

попробуй добавить в файлы, которые вызывают ошибки:

#include <linux/types.h>

Оказывается не у всех linux/fs.h подключает linux/types.h

Это было на работе на убунте, дома на слаке все завелось без бубнов.

> хотеть reiserfs

Добавил FIBMAP; работает медленно и только от рута — ограничение FIBMAP.

посмотрю потом
спс

Открыл для себя тот факт, что reiserfs записывает почти все большие файлы с разрывами, в которые вставляет метаданные. Это приводит к тому что фактически последовательно записанные файлы считаются фрагментированными только из за формально большого количества кусков. Само по себе число фрагментов стало ничего не говорящим просто числом. Поразмыслив, я выдумал другую метрику: считать скорость чтения файла, усредненную по некоторому окну (буфер чтения) и искать минимальную скорость для файла. Отношение сырой скорости к минимальной средней-по-окну и будет severity.

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

Собственно, что сказать хотел: я вставил поддержку этой метрики в свою программу; и теперь она не падает.

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

> Размер, который репрезентуют блоки adjustable?

Теперь да. Правда память очень любит: ~ 1.5 Gb на 100 Gb раздел для масштаба 1:1. Менять масштаб можно скроллом мышки, зажав Ctrl на клавиатуре.

Правда память очень любит: ~ 1.5 Gb на 100 Gb раздел для масштаба 1:1.

У меня нет таких денег © :D

> У меня нет таких денег © :D

Если сделать структуру данных о кластерах разреженной, потребление памяти значительно снизится, но пока не соображу, как подступиться. Сейчас просто пустой вектор clusters занимает 60% от всей памяти.

А пока можно ограничиться 1:10, это уже всего 150 Мб на 100 Гб.

Если сделать структуру данных о кластерах разреженной, потребление памяти значительно снизится

Сделал хранение данных о кластерах разреженным, потребление памяти снизилось (~170-200 MiB на раздел 200 GiB). Память выделяется и заполняется только когда есть необходимость показывать необходимую область.

Из остального — перешёл на gtkmm-3.0 и добавил список самых фрагментированных файлов, чтобы вручную не искать.