Forum Debian Users Gang

Próbuj go montować z opcją sync, wtedy zapis jest dosyć równy i chyba chodzi szybciej.
Jednak w przypadku udisk2 będziesz musiał go montować przez udeva.

Tu masz przykład:
https://forum.dug.net.pl/viewtopic.php?pid=293671#p293671
Z resztą chyba znasz lepsiejsze :D

Ostatnio edytowany przez Jacekalex (2015-12-02 17:54:23)

Odpowiednio dla 60, 240, 2048 i 32678.

logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./01 bs=1M count=1024 && sync"
1024+0 przeczytanych recordów
1024+0 zapisanych recordów
skopiowane 1073741824 bajty (1,1 GB), 7,22978 s, 149 MB/s

real    1m39.998s
user    0m0.000s
sys     0m1.256s


logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./02 bs=1M count=1024 && sync"
1024+0 przeczytanych recordów
1024+0 zapisanych recordów
skopiowane 1073741824 bajty (1,1 GB), 18,4323 s, 58,3 MB/s

real    1m42.057s
user    0m0.000s
sys     0m1.296s


logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./03 bs=1M count=1024 && sync"
1024+0 przeczytanych recordów
1024+0 zapisanych recordów
skopiowane 1073741824 bajty (1,1 GB), 23,3442 s, 46,0 MB/s

real    1m42.317s
user    0m0.000s
sys     0m1.312s


logan@toshiba:/mnt/1$ time sh -c "dd if=/dev/zero of=./04 bs=1M count=1024 && sync"
1024+0 przeczytanych recordów
1024+0 zapisanych recordów
skopiowane 1073741824 bajty (1,1 GB), 24,6953 s, 43,5 MB/s

real    1m41.023s
user    0m0.008s
sys     0m1.292s

@Jacekalex, u mnie opcja sync = kompletna degradacja transferu, który zwykle wynosi parę KiB/s xD Z reguły transfer jest mniej więcej taki jaki widać, tj. po zakończeniu kopiowania, sync praktycznie przechodzi od razu i dioda na penie przestaje migać.

U mnie na sync chodzi normalnie, bez sync transfer wygląda, jak żeby piły, zaczyna szybko, a potem zjeżdża do niemal zera.

PS
Pendrak - stary Kingston.

Nie będę się tu rozpisywał, odsyłam jedynie do konstrukcji typu "multibit per cell" i zwracam uwagę że to nie jest SLC.
Może wyjść rozbieżność nawet 50% zgodnie z notami katalogowymi części układów. Następnie popatrz w jakich porcjach wysyłasz dane z dd. Rozrzut powodowany na warstwie sprzętu potęguje rozjechanie buforów i ich wielkości. Oraz sposób pracy samych programów od strony kodu maszynowego w takich wyjątkach.
Chyba o tym że w łańcuchu jest jeszcze chipset i kontroler nie muszę wspominać i tutaj też jest kolejkowanie, a drugi posiada dodatkowo swój bufor.

W sumie fakt, zasugerowałem się tym transferem z dd. xD Powinniście sobie skonfigurować te dirty pages. Wtedy nie będzie takiej sytuacji gdzie system kończy kopiować, a i tak jeszcze dane się zapisują na nośnik przez parę minut. xD

U mnie jest poprawa i to widać wyraźnie przy zmianie wartości. To nie tylko jeden przypadek. Generalnie ja to sobie testowałem tak by wyeliminować jakąś przypadkowość ale zawsze przy zmianie z tej domyślnej na większą dostaje 2M/s gratis. xD Wątpię by to było za sprawą systemd, może taki pendrive albo coś innego.

@qluk, to jak ten test miałby wyglądać by dać miarodajne wyniki?

Ostatnio edytowany przez morfik (2015-12-02 20:49:45)

Z tego wykresu wychodzi, że zależność jest i im większa wartość tym szybciej, przynajmniej do określonego momentu, także nie jestem odosobnionym przypadkiem. Teraz pytanie jaka jest optymalna wartość i czy da się ją jakoś wyliczyć bez strzelania na ślepo. xD W FAQ o USB piszą, że ta wartość ma być wielokrotnością 8 lub 16, odpowiednio dla 32bit i 64bit systemów. Więc, te 60 to trochę nietrafione. xD Pisza, też że nie ma górnego limitu ani nie ma co jechać więcej niż 2048.

Czym zrobić taki grafik?