Издирвам тестери за 64bit linux udf

[stoar08]

С малко думички, че кафето свърши вчера - преди 2-3 дни ме осени прозрението, че щом си имам udf-а мога сам да си го port-на на linux (по-специално 64 битов, понеже от 32 битовия май само аз се оплаквах и едно време).

"Сериозна промяна" съм правил само в засичането на hdd serial, понеже там имах проблеми. По другите места съм вложил козметични виждания за нещата и като цяло не очаквам изненади.

Като осъмна започвам да го тествам и ще се постарая до 5-10 дни да пусна база в/у него (в най-лошия случай само мойта лична в офиса). Ако някой има желание/необходимост/възможност за проба - да драсне 1 ред да му пусна файла по мейл

[morphieus]

имаш ли ми email-a

[boris]

Това единствено за 64 битов ли е, защото съм с 32 , ако има чалъм за него ще ти пратя email-a?

[stoar08]

Това единствено за 64 битов ли е, защото съм с 32 , ако има чалъм за него ще ти пратя email-a?

По принцип няма нищо специфично за 64, но такава машинка съм си спретнал за експеримента. Ако имаш проблеми с другия - дай mail и ще намеря на какво да го компилирам.

[invisible]

Само удиефчето ли ще ми пратиши да тествам с вине или имаш някакъв по специален линукс?

[stoar08]

Към момента единственото "изискване" е наличието на grep в/у машината, понеже не ми се занимаваше с едни глупости.
Компилирам го в/у glibc 2.12 и kernel 2.6.35, но би трябвало да върви без проблеми на произволна дистрибуция (ако случайно излезе проблем с някоя ще си инсталирам за да разуча какво не и харесва).

ПС За момента само правенето на нови криптирани записи в касата дава проблем (вече направените с udf-а от сайта се четат нормално), което ще го изгладя в близките ден-два.

[stoar08]

Да побързам да се похваля - първата функционална машина вече е факт (пак трябва да черпя morphieus ) и работи с 64 bit Firebird Classic.
UDF-а е завършен като функционалност и за момента изглежда стабилен.


ПС Редактирах темата като анкета - споделяйте:)

[morphieus]

Конфигурацията е следната: 2 физически обекта (единият отдалечен - работи през интернет 3 станции) и 6 локални станции. Четенето в базата е на доста задоволително положение (двойно се ускори справка сметки), извличането на друг вид данни (Други справки) също е на впечетляващо ниво. Използваме двупроцесорната работа на сървъра. РАМ-та е DDR3, процесора е Е8400 3Гхз (6МВ L2 cache). При един гигабайт база, справка сметки се извлича за 5-6 секунди без значение колко е натоварена работата.

До тук с всичко хубаво. Към момента се наблюдава в обекта един странен проблем.
При запис на операции се наблюдава бавене, което е относително (според количеството на продуктите в операцията), наблюдавани операции: продажба, вр. стока от клиент, производство. Бавенето е от порядъка на до 10-12сек.

Предстои тези дни тест върху SSD носител за съпоставка с текущите параметри.

[stoar08]

При един гигабайт база, справка сметки се извлича за 5-6 секунди без значение колко е натоварена работата.

...

До тук с всичко хубаво. Към момента се наблюдава в обекта един странен проблем.
При запис на операции се наблюдава бавене, което е относително (според количеството на продуктите в операцията), наблюдавани операции: продажба, вр. стока от клиент, производство. Бавенето е от порядъка на до 10-12сек.

Лъжа, нагла лъжа, статистика

Код: Избери всички

-bash-4.1# time { /opt/firebird/bin/gbak -user sysdba -password masterkey -z -r /storage/backup/mpetrov/200910_185900.fbk /storage/db/test.fdb ; }
gbak:gbak version LI-V2.1.3.18185 Firebird 2.1
gbak:    Version(s) for database "/storage/db/test.fdb"
        Firebird/linux AMD64 (access method), version "LI-V2.1.3.18185 Firebird 2.1"
        on disk structure version 11.1

real    3m15.878s
user    3m1.707s
sys     0m5.172s

Код: Избери всички

-bash-4.1# time { /storage/backup/scripts/fb_clean.sh && /storage/backup/scripts/backup.sh ; }  
Parallel BZIP2 v1.1.1 - by: Jeff Gilchrist [http://compression.ca]
[Apr. 17, 2010]             (uses libbzip2 by Julian Seward)
Major contributions: Yavor Nikolov <nikolov.javor+pbzip2@gmail.com>

         # CPUs: 2
 BWT Block Size: 900 KB
File Block Size: 900 KB
 Maximum Memory: 100 MB
-------------------------------------------
         File #: 1 of 1
     Input Name: <stdin>
    Output Name: <stdout>

Compressing data...
    Output Size: 87262344 bytes
-------------------------------------------

     Wall Clock: 46.016456 seconds

real    0m46.028s
user    1m28.950s
sys     0m1.464s

ПС Нито бързите справки, нито бавните записи на сметки има отношение към UDF-a. Просто мисля, че е крайно време да се яви "наш" линукс, който да е аналог на Novell времената 8) .

[morphieus]

Че кой е хвърлил вината върху UDF-a ? Аз не съм!

P.S. Тази сутрин няма оплаквания от времето за запис на операциите

[stoar08]

Е, udf-а се държи стабилно (все още ).
Реших тук да пиша едно интересно наблюдение по повод windows/linux.
На кратко - Forced Writes под Windows не работят (или поне не според моите разбирания). Играя си 2-3 дена и съвсем отговорно заявявам, че разликата между win и lin може да се мери единствено след изключване на FW на втория.

За експеримет ползвам преизчисление на 1 продукт (1 и същи по всички тестове е) и разпъване на база.

1 Под Windows включване/изключване на Forced Writes дава разлика от около 5 секунди на 75, което е в рамките на статистическата грешка. Под linux разликата е от 4 минути (при включени FW) до 63 секунди (след изключването)...

2 На SAS Raid-а, при стандартна конфигурация - въпросното преизчисление отнема 4.5-5.5 минути, според тип-а масив (mirror/span). След пускане на всички кешове (които няма как да намалят времето за "гравиране" в/у плочите), същите времена падат на 1.5-2 минути. И в 2та случая FW са включени.

3 Разпъването на базата отнема около 26 минути под Win 2003 и около 20 минути под x64 linux