Nebude moc zalezet na rozdeleni, pokud to neni extra.
SD karta ma vlastni wear leveling system tj. postupne opotrebuje vsechny bloky (mozna nektere osizene karty to delaji jen pres par bloku), ale obecne pres vsechny, neboli jak je karta rozdelena je jedno.
Karta by mela by x krat vetsi nez co tam ukladate, aby wear leveling fungoval dobre tj., aby se mohlo menit s bloky, ktere jsou malo pouzivane.
Zkuste si nainstalovat iostat, vmstat ci neco podobneho a sledujte kolik zapisu se deje. To muzete zkusim minimalizovat vypnutim swapu a dalsich programu presmerovanych na zapis do tmp system v ram.
Nicmene za vsechno se plati, nektere programy jako prohlizec si natahuji videa, pokud nebude dostatek pameti, tak Vam prohlizec spadne, ... .
Jirka
Dne 3. 6. 2016 v 16:26 Michal Grunt napsal(a):
> Můžete prosím napsat jak by karta měla být správně rozdělena? Děkuji.
>
> Dne 3. června 2016 12:54 Václav Ovsík <vaclav.ovsik na gmail.com> napsal(a):
>> On Fri, Jun 03, 2016 at 12:29:11PM +0200, iko wrote:
>>> co mate za SD kartu ze podporuje TRIM?
>>>
>>> On 06/03/2016 12:19 PM, Václav Ovsík wrote:
>>>> no a rozdelujete peclive kartu, aby byly oddily zarovnane na erase
>>>> bloku? Ja teda nainstaloval na RPi Debian a vypudil jsem vetsinu veci
>>>> co neco zapisovala. Neudelal jsem pochopitelne zadny swap a vypudil
>>>> rsyslog. Staci ten runtime log od journal (systemd) co je v /run
>>>> (ramdisk). Nedal jsem pri mountovani discard, protoze to je pomalejsi,
>>>> ale obcas - kdyz se neco umaze spustim fstrim. Zatim puvodni 8G
>> Myslim, ze vsechny karticky Transcend co jsem kupoval zatim trim umely.
>> Resp. takhle - netusim jestli to skutecne podporuje trim, nebo to nejak
>> osvindluje jadro a bloky proste samo vynuluje, ale mel bych tendenci
>> verit, ze to fakt funguje, podle casove prodlevy - tak rychle by se to
>> nezapsalo "rucne". Kdyz jsem dal trim (blockdiscard) na celou karticku,
>> tak je proste v tu ranu vynulovana (no po par sekundach - ted to zkouset
>> nebudu jak rychle :).
>>
>> Ted nejsem doma u RPi, ale v blbniku v Zimu mam napsano:
>>
>> | microSDHC pro RPi
>> |
>> | cd /sys/class/mmc_host/mmc?/mmc?:*
>> | echo "man:$(cat manfid) oem:$(cat oemid) name:$(cat name) hwrev:$(cat hwrev) fwrev:$(cat fwrev)"
>> |
>> |
>> | man:0x000074 oem:0x4a60 name:USD hwrev:0x0 fwrev:0x2
>> |
>> | bobek:/sys/class/mmc_host/mmc0/mmc0:59b4# for x in *; do [ -f "$x" ] && echo "$x: $(cat $x)"; done
>> | cid: 744a6055534420200256a317c100f200
>> | csd: 400e00325b5900003c1d7f800a400000
>> | date: 02/2015
>> | erase_size: 512
>> | fwrev: 0x2
>> | hwrev: 0x0
>> | manfid: 0x000074
>> | name: USD
>> | oemid: 0x4a60
>> | preferred_erase_size: 4194304
>> | scr: 0235800100000000
>> | serial: 0x56a317c1
>> | type: SD
>> | uevent: DRIVER=mmcblk
>> | MMC_TYPE=SD
>> | MMC_NAME=USD
>> | MODALIAS=mmc:block
>> |
>> |
>> | attr viz https://www.kernel.org/doc/Documentation/mmc/mmc-dev-attrs.txt
>> |
>> | looking at device '/class/mmc_host/mmc0/mmc0:59b4':
>> | KERNEL=="mmc0:59b4"
>> | SUBSYSTEM=="mmc"
>> | DRIVER=="mmcblk"
>> | ATTR{cid}=="744a6055534420200256a317c100f200"
>> | ATTR{csd}=="400e00325b5900003c1d7f800a400000"
>> | ATTR{scr}=="0235800100000000"
>> | ATTR{date}=="02/2015"
>> | ATTR{name}=="USD "
>> | ATTR{type}=="SD"
>> | ATTR{preferred_erase_size}=="4194304"
>> | ATTR{fwrev}=="0x2"
>> | ATTR{hwrev}=="0x0"
>> | ATTR{oemid}=="0x4a60"
>> | ATTR{manfid}=="0x000074"
>> | ATTR{serial}=="0x56a317c1"
>> | ATTR{erase_size}=="512"
>> |
>> |
>> | Device Boot Start End Sectors Size Id Type
>> | /dev/mmcblk0p1 8192 15759359 15751168 7.5G b W95 FAT32
>> |
>> |
>> | bobek:/opt# fsck.vfat -v /dev/mmcblk0p1
>> | fsck.fat 3.0.27 (2014-11-12)
>> | Checking we can access the last sector of the filesystem
>> | Boot sector contents:
>> | System ID " "
>> | Media byte 0xf8 (hard disk)
>> | 512 bytes per logical sector
>> | 32768 bytes per cluster
>> | 4348 reserved sectors
>> | First FAT starts at byte 2226176 (sector 4348)
>> | 2 FATs, 32 bit entries
>> | 984064 bytes per FAT (= 1922 sectors)
>> | Root directory start at cluster 2 (arbitrary size)
>> | Data area starts at byte 4194304 (sector 8192)
>> | 245984 data clusters (8060403712 bytes)
>> | 63 sectors/track, 255 heads
>> | 8192 hidden sectors
>> | 15751168 sectors total
>> | Checking for unused clusters.
>> | Checking free cluster summary.
>> | /dev/mmcblk0p1: 0 files, 1/245984 clusters
>> |
>> |
>> | schovaných prvních 8MB originálního rozdělení a VFAT: ./usdhcTranscend8GB-first8MB.bin.gz
>> |
>> | http://lists.linaro.org/pipermail/flashbench-results/2013-September/000457.html
>> |
>>
>> Musim rici, ze me dost prekvapuje jak malo se venuje optimalnimu
>> rozdeleni filesystemu na SD kartickach vzhledem k tomu jak je to
>> dulezite. Snazil jsem se o neco, ale stejne netusim jestli jsem to
>> udelal optimalne. Zatim mi ale karticka neumrela, tak jsem nebyl
>> motivovan vice...
>>
>> --
>> Zito
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list