On 2017-01-27 23:01, Dariusz Dorochowicz wrote:
>> Niektóre mostki usb->sata ignoruja błedy transmisji i zapisują byle co.
>> I to wcale nie te najtańsze chińskie. Sam byłem zdziwiony że mozna
>> zapisać plik kilka GB i za kadym razem znaleźc po kilka tysięcy
>> przypadkowych bajtów o innych wartościach. Wymiana kabla pomogla, ale
>> niesmak pozostał. Dziadostwo.
> A jakieś szczegóły pamiętasz? Bo faktycznie parę lat temu na coś
> podobnego trafiłem, ale to jeszcze było za czasów IDE.

Nie, ponieważ nie pozwolono mi ściągnąć plomb. To był kupny dysk w
obudowie. Doczytalem na internetach że generowały błedy zapisu przy
kiepskich kablach. Doczytałem tez że był na scalaku Ali, ale one
wszystkie są na Ali ;) Potem ktoś dopisał że ten sam defekt mają
niektóre przelotki SATA do usb i sa na tym samym scalaku. Od tej pory
nie daje wiary takim zabawkom [1].

[1] Choć właśnie kupiłem w chinach obudowę USB 3.0->SATA za bezcen.
Dziala jak huragan. Nikt by się nie spodziewał że wyciąga pelne pasmo dysku.

do góry

W dniu 2017-01-27 o 23:14, Sebastian Biały pisze:
> On 2017-01-27 23:01, Dariusz Dorochowicz wrote:
>>> Niektóre mostki usb->sata ignoruja błedy transmisji i zapisują byle co.
>>> I to wcale nie te najtańsze chińskie. Sam byłem zdziwiony że mozna
>>> zapisać plik kilka GB i za kadym razem znaleźc po kilka tysięcy
>>> przypadkowych bajtów o innych wartościach. Wymiana kabla pomogla, ale
>>> niesmak pozostał. Dziadostwo.
>> A jakieś szczegóły pamiętasz? Bo faktycznie parę lat temu na coś
>> podobnego trafiłem, ale to jeszcze było za czasów IDE.
>
> Nie, ponieważ nie pozwolono mi ściągnąć plomb. To był kupny dysk w
> obudowie. Doczytalem na internetach że generowały błedy zapisu przy
> kiepskich kablach. Doczytałem tez że był na scalaku Ali, ale one
> wszystkie są na Ali ;) Potem ktoś dopisał że ten sam defekt mają
> niektóre przelotki SATA do usb i sa na tym samym scalaku. Od tej pory
> nie daje wiary takim zabawkom [1].
>
(...)

Ja tak miałem z pier... Samsungiem D3 Station, p/n HX-D301TDB/G. Ten
sq... nie lubił się z niektórymi kablami USB3, z którymi to kablami inne
dyski działały prawidłowo. A ile się nakląłem zanim to zauważyłem. A ile
razy przegrywałem duże pliki (bo na małych problem występował
sporadycznie). A przy okazji, na samym początku, straciłem ważny obraz
Ghosta - bo z przyzwyczajenia kopiowałem bez weryfikacji.
Ostatni raz weryfikację to włączałem chyba jeszcze za czasów dysków MFM.


--
Pozdrawiam.

Adam

do góry

Dnia 27.01.2017 Sebastian Biały <h...@p...onet.pl> napisał/a:
> On 2017-01-27 11:54, Ghost wrote:
>> A powód, że nie zwykła karta pamięci to wielkość/taniość?
>
> Podstawowym powodem dla ktorego nalezy unikać kart pamięci jest wear
> leveling. Karta w sposób swobodny zamienia ze soba miejscami fragmenty
> flasha. Jest w momencie takiej operacji zniknie zasilanie masz
> uszkodzony *przypadkowy* kawałek filesystemu. Na przykład dowolny plik
> systemowy. W niektórych modelach kart masz *gwarantowane* trwale i
> nieodwracalne uszkodzenie jesli nie zamkniejsz poprawnie systemu a
> wyłączysz zasilanie w trakcie zapisu.
>
> Albo trzeba stosować specjalne karty odporne na to, albo darowac sobie
> trzymanie danych na SD, zrobić ją read-only i system na niej robi kexec
> na jądro z dysku twardego.
>
> PS. Tak, znam ludzi którym to się nigdy nie przytrafiło. Ale to bardziej
> kwestia ich szczęscia.
>

Nadają się wyłącznie na przechowywanie danych przeznaczonych na
śmietnik. Na nic więcej. Wyłącznie do odczytu.

Inny istotny problem z nimi to taki że są "optymalizowane" pod FAT-y.
https://en.wikipedia.org/wiki/Secure_Digital#File_sy
stem
http://3gfp.com/wp/2014/07/formatting-sd-cards-for-s
peed-and-lifetime/

Istnieje szczególnie duże ryzyko, że po przeformatowaniu dane wyparują
momentalnie. Raptem kilka dni temu nabyłem taki wynalazek SDHC za kilka
złotych. Wytrzymała 5h (ani minuty więcej).
Posiadam 2G kupioną w 2008 roku. Działa do dziś. Siedzi sobie w tym
momencie w czytniku jako / - rootfs i ma się dobrze, odpukać.
Nie ma w tym przypadku - nowa została "zoptymalizowana".

Inny kłopot z nimi, że z tego dziadostwa haracz trafia do:
"SDHC is patented trademark of SD-3C, LLC founded by Panasonic, Sandisk
and Toshiba. Licences for memory card manufacturers (e.g. microSDHC
card) and adapter manufactureres (e.g. reader installed in a tablet) are
available via an independent member organization SDA.

The current executive members includes Microsoft corporation."
http://reviewjolla.blogspot.fi/2015/01/jolla-tablet-
microsd-support-what.html

do góry

Dnia 27.01.2017 Atlantis <m...@w...pl> napisał/a:
> W dniu 2017-01-27 o 22:32, Sebastian Biały pisze:
>
>> uszkodzony *przypadkowy* kawałek filesystemu. Na przykład dowolny plik
>> systemowy. W niektórych modelach kart masz *gwarantowane* trwale i
>> nieodwracalne uszkodzenie jesli nie zamkniejsz poprawnie systemu a
>> wyłączysz zasilanie w trakcie zapisu.
>
> Ja już w ogóle miałem dziwne doświadczenia z kartami pamięci i Raspberry
> Pi. Kiedyś próbowałem odpalić Raspbiana, stosując dopiero co kupioną
> kartę. Nie pamiętam już jaka firma - ani chiński "no name", ani porządny
> SanDisk - raczej coś stojącego w połowie drogi między nimi. Karty tego
> samego typu wcześniej stosowałem już w paru projektach z
> mikrokontrolerami i zawsze działały prawidłowo.
> Zainstalowałem Raspbianna, zaktualizowałem go, zrobiłem jakąś podstawową
> konfigurację i wstępnie skonfigurowałem. Już wtrakcie wykonywania
> "apt-get upgrade" zaczął sypać błędami. Po restarcie już nie wstał -
> błąd systemu plików.
> Druga karta tego samego typu zachowała się w dokładnie ten sam sposób.
>
>
>> PS. Tak, znam ludzi którym to się nigdy nie przytrafiło. Ale to bardziej
>> kwestia ich szczęscia.
>
> Mi już raz system plików na Raspberry Pi wysypał się przy okazji awarii
> zasilania...
>

Jak padają, to nic nie poradzisz. Duża pewność, że system plików zawsze
został przemontowany w tryb read-only.
Wystarczy choćby SysRq+s,u lub
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger

Maksymalne ograniczenie liczby jakichkolwiek bezpośrenich zapisów.
Sprawdzasz co, gdzie i kiedy zapisuje:
echo 1 > /proc/sys/vm/block_dump
i zatrzymujesz
echo 0 > /proc/sys/vm/block_dump

Maksymalnie duże wartości (10 minut - 60000) w
/proc/sys/vm/dirty_writeback_centisecs
/proc/sys/vm/dirty_expire_centisecs
Stosowanie Zram, overlafs i sto innych tricków.

do góry

Dnia 27.01.2017 Atlantis <m...@w...pl> napisał/a:

> Mi już raz system plików na Raspberry Pi wysypał się przy okazji awarii
> zasilania...
>
Bo i też jest różnica w zostosowaniach. Typowe ich zastosowanie to
trzymanie 20 doców, 100 jpg, 500 mp3 i 2 filmów. Gdy system plików musi
obsłużyć 200000 plików w tym często je aktualizując to o marny ich
koniec nie trudno.

do góry

Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:o6ge97$f0r$...@n...news.atman.pl...

On 2017-01-27 11:54, Ghost wrote:
>> A powód, że nie zwykła karta pamięci to wielkość/taniość?

>Podstawowym powodem dla ktorego nalezy unikać kart pamięci jest wear
>leveling. Karta w sposób swobodny zamienia ze soba miejscami fragmenty
>flasha. Jest w momencie takiej operacji zniknie zasilanie masz uszkodzony
>*przypadkowy* kawałek filesystemu. Na przykład dowolny plik systemowy. W
>niektórych modelach kart masz *gwarantowane* trwale i nieodwracalne
>uszkodzenie jesli nie zamkniejsz poprawnie systemu a wyłączysz zasilanie w
>trakcie zapisu.

>Albo trzeba stosować specjalne karty odporne na to, albo darowac sobie
>trzymanie danych na SD, zrobić ją read-only i system na niej robi kexec na
>jądro z dysku twardego.

1. Zwykle karty są odporne na to, albowiem tylko niewiele typów kart używa
static wear lavelling (co wyżej opisałeś). Większościowy dynamic nie ma
takiej przypadłości. Dodatkowo nie wszystkie karty static maja szanse
spowodować pad, kwestia algorytmu.
2. Dodatkowo twój pomysł z read-only jest tez do kitu, bo karty ze static
wear lavelling nawet przy odczycie mogą dokonywać przesunięć bloków.

Ergo: wiesz, ze cos dzwoni, ale twoje rady są wręcz szkodliwe.

>PS. Tak, znam ludzi którym to się nigdy nie przytrafiło. Ale to bardziej
>kwestia ich szczęscia.

Bardziej interesujące jest to, jak ktoś stwierdził, ze przyczyna padu był
akurat static wear lavelling przy power loss?

do góry

On Fri, 27 Jan 2017 23:12:57 -0000 (UTC), grapeli23
<g...@g...com> wrote:
> Nadają się wyłącznie na przechowywanie danych przeznaczonych na
> śmietnik. Na nic więcej. Wyłącznie do odczytu.

No bo do zastosowan gdzie ma być pewność zapisu/odczytu używa się
kart orzemyskowych np. taka karta 4GB ap-msdd04gcs4p-1tm kosztuje
circa 800 pln,

--
Marek

do góry

On 2017-01-28 10:12, Ghost wrote:
> 1. Zwykle karty są odporne na to, albowiem tylko niewiele typów kart
> używa static wear lavelling (co wyżej opisałeś). Większościowy dynamic
> nie ma takiej przypadłości. Dodatkowo nie wszystkie karty static maja
> szanse spowodować pad, kwestia algorytmu.
> 2. Dodatkowo twój pomysł z read-only jest tez do kitu, bo karty ze
> static wear lavelling nawet przy odczycie mogą dokonywać przesunięć bloków.

Pomysł jest mniej do kitu bo jak masz karte read-only tylko z kernelem a
możesz tam wsadzić kartę o rozmiarze 256MB która nie ma żadnych sztuczek
relokowania flasha i kosztuje mniej. Tada!

> Ergo: wiesz, ze cos dzwoni, ale twoje rady są wręcz szkodliwe.

A szkodliwośc polega na? Co szkodliwego w kexec na dysk? Imbecyle pisali
bootloader (nie pozwala na boot z hdd) ale kexecem to obejdę. Co złego w
tej radzie? Moze jednak masz rade kupic kartę za 1000zł? Ja mam rade
kupić kartę 256MB i zrobić kexec na dysk, lub wrecz zostawić kernel na
karcie a zamontować roota z dysku.

>> PS. Tak, znam ludzi którym to się nigdy nie przytrafiło. Ale to
>> bardziej kwestia ich szczęscia.
> Bardziej interesujące jest to, jak ktoś stwierdził, ze przyczyna padu
> był akurat static wear lavelling przy power loss?

Kiedy wyszło PI pojawił się problem z tym że tylko niektóre karty
pracowaly prawidłowow, a te które były sugerowane też padały tylko po
dłuższym czasie. Pół internetu szukało przyczyny. Przyczyna okazał się
być wear levelling. I nie ma to sensownego rozwiązania. W moim PI
dorobiłem kondensator i rezysto na zasilaniu. Rozwiązanie takie sobie,
ale załatwiło problemy w mało ważnym urzadzeniu. W bardzo ważnym
urzadzeniu zamiast tego jest kexec.

do góry

W dniu 2017-01-27 o 22:39, Atlantis pisze:
> Co rozumiesz przez "taką sobie stabilność"?:)

Mogę tylko mówić o Orange PI Lite + armbian.
Jedyny sposób komunikacji z tym to wbudowane Wi-Fi.
Po kilkunastu godzinach pracy systemu połączenie Wi-Fi staje się
niestabilne, połączenie się zrywa, zaczyna działać po kilkudziesięciu
sekundach, kilku minutach.
Restart systemu i znowu kilkanaście godzin bez problemu.

--
AWa.

do góry

Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:o6hrnc$opf$...@n...news.atman.pl...

>> Ergo: wiesz, ze cos dzwoni, ale twoje rady są wręcz szkodliwe.

>A szkodliwośc polega na?

Na zapewnieniu, ze sam odczyt zabezpiecza przed statycznym levellingiem.

>>> PS. Tak, znam ludzi którym to się nigdy nie przytrafiło. Ale to
>>> bardziej kwestia ich szczęscia.

>> Bardziej interesujące jest to, jak ktoś stwierdził, ze przyczyna padu
>> był akurat static wear lavelling przy power loss?

>Kiedy wyszło PI pojawił się problem z tym że tylko niektóre karty pracowaly
>prawidłowow, a te które były sugerowane też padały tylko po dłuższym
>czasie. Pół internetu szukało przyczyny. Przyczyna okazał się być wear
>levelling.

Ta, i jeszcze dopisz, ze dynamiczny.

do góry