Hi,

Poruszyłeś fajny temat - rzeka :) Mogę się mylić co do niektórych
rzeczy, to jak coś to mnie poprawiajcie.

On 10/07/2020 15:48, pueblo wrote:

Wiem, że z technicznych powodów nie powinno się zapełniać SSD w całości. Zresztą system na pełnym hdd też będzie miał problemy.

HDD mechaniczny "nie rozumie" zajętości i go to zupełnie nie obchodzi -
dane są przechowywane cały czas i wszędzie, czy to w wolnych sektorach
czy zajętych. Możesz mieć HDD zapełniony w 100% i jego to nie boli.

Ale co do ssd - czy to jest reguła dotycząca każdego takiego sprzętu? Najtańszego i tego klasowego?

Niestety każdy SSD ma problem z wear leveling i wynalezione zostały
technologie, aby temu nierównemu zużywaniu się zapobiegać - czyt. niżej

Podobno należy zostawić 20% wolnego. Mniej bym się przejmował gdyby prędkości R/W spadły 2 albo 3 krotnie od maks. po zapełnieniu ponad to niż tego, że spadnie jakoś odczuwalnie czas dostępu.

W miarę zużywania się komórek spada R/W bandwidth i czas dostępu też
rośnie (do komórek, które już ileś tam razy były zapisane wcześniej),
nic na to nie poradzisz.
Dzisiejsze dyski i system operacyjne obsługują TRIM - a więc wolne
miejsce w twoim systemie plików, czy to NTFS czy Ext4, jest tym wolnym,
nie zajętym obszarem z punktu widzenia kontrolera. I on tego miejsca
używa, tak samo jak używa tego twojego 20% wolnego.
Ja na przykład nie mam żadnego miejsca wolnego bez wydzielonej partycji,
dwie partycje jedna NTFS na Windows 10 i druga Ext na Linuksa w pełni
wykorzystują SSD - używam obu systemów, oba obsługują TRIM, oba wysyłają
sygnały kontrolerowi, aby wolnego miejsca używał do woli i je
zerował/wykorzystywał komórki ponownie.
Na Linuksie ponadto wywołuję komendę TRIM ręcznie co tydzień, dla
partycji Ext4.

I jeszcze jedno mnie zastanawia. Jeśli jest ssd np. 200GB i ktoś ma

stały

zestaw 100GB zapisanych danych, które nie są modyfikowane, to
pracuje,"zużywa się" tylko pozostałe 100GB? Nie ma żadnej rotacji
niezależnej od usera gdzieś w tle tak, żeby cały obszar pamięci był w
miarę równomiernie ekspolatowany?

Kontrolery SSD w dzisiejszych czasach to robią, na bieżąco swapują
sektory, jeśli któryś sektor "leży" z zapisanymi danymi za długo i
potrzebuje za dużo ECC (korekcji błędów), aby w ogóle zostać odczytany,
to zostaje nadpisany ponownie/zwolniony z użytku itd. Swego czasu
sławetny był Samsung, nie robili aktywnego scrubbingu sektorów w tle i
zwalniał bandwidth bardzo mocno, po tej akcji wypuścili aktualizację
firmware, aby kontroler cały czas w tle jeździł po sektorach, czytał je
i sprawdzał, czy wszystkie da się jeszcze w miarę szybko odczytać i
jakby co naprawiał problem. Co oczywiście skraca żywotność dysku, ale
coś za coś.

--
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

Witaj pioruns, 10 lip 2020 w
news:rea2a3$8a1$1$piorunsnews.chmurka.net napisałeś/aś:

On 10/07/2020 15:48, pueblo wrote:

Wiem, że z technicznych powodów nie powinno się zapełniać SSD w
całości. Zresztą system na pełnym hdd też będzie miał problemy.

Możesz mieć HDD zapełniony w 100% i
jego to nie boli.

Dlatego napisałem, że OS będzie mieć problemy

TRIM - a więc wolne
miejsce w twoim systemie plików, czy to NTFS czy Ext4, jest tym
wolnym, nie zajętym obszarem z punktu widzenia kontrolera. I on tego
miejsca używa, tak samo jak używa tego twojego 20% wolnego.

Dla jasności. Miałem na myśli wykorzystanie całej pojemności dostępnej dla użyt. na system plików i pilnowanie żeby jej nie zapełnić powyżej 80%. W sumie nawet nie pomyślałem, że można po prostu zostawić jakiś procent niespartycjonowany. Chyba napisałeś tylko o zużyciu, co nie wydaje mi się problemem, bo wydaje mi się że przeciętny user b. długo nie zajedzie takiego dysku ilością R/W.
Ale jakoś nie wychwyciłem nic odnoście konieczności bądź jej braku pzostawienia w ten czy inny sposów jakiegoś % wolnej przestrzeni.
Mama rozumieć, że to oczywista oczywistość? Czy zależy właśnie od klasy sprzętu?
W międzczasie dowiedziałem się o istnieniu Over-provisioning
https://en.wikipedia.org/wiki/Write_amplification#Over-provisioning

I tu mi przyszło głupie pytanie do głowy - dlaczego są pojemności typu 240, 250, 256? Czy np. dysk 240 ma tę samą realną pojemność co 256, tylko ma więcej wolnej przestrzeni (Overprovisioning) zostawionej przez producenta?

Kontrolery SSD w dzisiejszych czasach to robią, na bieżąco swapują
sektory, jeśli któryś sektor "leży" z zapisanymi danymi za długo i
potrzebuje za dużo ECC (korekcji błędów), aby w ogóle zostać
odczytany, to zostaje nadpisany ponownie/zwolniony z użytku itd.

To świetnie. Czy w ssd też jest tak, że jest jakaś pula komórek(bad sectorów), które mogą być do wyczerpania tej puli podmienione?
A propos bad sectorów i smart. Nadal nie wiem, czy jeśli dysk hdd raportuje realokowane sektory, to znaczy, że ta niewidoczna pula zapasowych się wyczerpała, czy każde takie zdarzenie. To nie jest takie pewne, bo chyba nawet jak Smart pokazuje realokację, to bywa że pełny skan dysku jest czysty i nie pokazuje badów.

Wcale nie przypadkiem, dnia 10 Jul 2020 17:05:03 GMT  doszła do mnie wiadomość  <5f089fbf$0$526$65785112@news.neostrada.pl>  od pueblo <nomail@nomail.pl>  :

Witaj pioruns, 10 lip 2020 w
news:rea2a3$8a1$1$piorunsnews.chmurka.net napisałeś/aś:

On 10/07/2020 15:48, pueblo wrote:

Wiem, że z technicznych powodów nie powinno się zapełniać SSD w
całości. Zresztą system na pełnym hdd też będzie miał problemy.

Możesz mieć HDD zapełniony w 100% i
jego to nie boli.

Dlatego napisałem, że OS będzie mieć problemy

Może boleć, nawet HDD -> dyski SMR:
https://pl.wikipedia.org/wiki/Shingled_magnetic_recording

TRIM - a więc wolne
miejsce w twoim systemie plików, czy to NTFS czy Ext4, jest tym
wolnym, nie zajętym obszarem z punktu widzenia kontrolera. I on tego
miejsca używa, tak samo jak używa tego twojego 20% wolnego.

Dla jasności. Miałem na myśli wykorzystanie całej pojemności dostępnej dla użyt. na system plików i pilnowanie żeby jej nie zapełnić powyżej 80%. W sumie nawet nie pomyślałem, że można po prostu zostawić jakiś procent niespartycjonowany.

Lepiez jest zostawić jakiś obszar niespartycjonowany, jest wtedy gwarancja, że obszar
będzie składał się z całych wolnych bloków(blok podzielony jest na strony o wielkości
4-16KiB) wobec czego zapis blokowy będzie szybszy(w obrębie strony występują wolne bloki
jeden za drugim, nie trzeba skakać z zapisami po odległych stronach).

Chyba napisałeś tylko o zużyciu, co nie wydaje mi się problemem, bo wydaje mi się że przeciętny user b. długo nie zajedzie takiego dysku ilością R/W.
Ale jakoś nie wychwyciłem nic odnoście konieczności bądź jej braku pzostawienia w ten czy inny sposów jakiegoś % wolnej przestrzeni.
Mama rozumieć, że to oczywista oczywistość? Czy zależy właśnie od klasy sprzętu?
W międzczasie dowiedziałem się o istnieniu Over-provisioning
https://en.wikipedia.org/wiki/Write_amplification#Over-provisioning

I tu mi przyszło głupie pytanie do głowy - dlaczego są pojemności typu 240, 250, 256? Czy np. dysk 240 ma tę samą realną pojemność co 256, tylko ma więcej wolnej przestrzeni (Overprovisioning) zostawionej przez producenta?

Oczywiście, producenci dają różne OP i różne ilości sektorów zapasowych.
Poza tym firmware też ma swoje tabele danych, czasami dość spore, które to tabele powinny
znajdować się w obszarach zarezerwowanych, wyłączonych z przechowywania danych
usera(przykładowo tabele wykorzystywane przez FTL, normalnie wczytywane do RAM kontrolera
SSD i uaktualniane po każdym zapisie, tak w uproszczeniu, bo jest wiele tabel FTL aby
dysk nie musiał zapisywać na flash jednej, ogromnej tabeli, tylko małą tabele opisującą
obszar, do którego trafił zapis).

Kontrolery SSD w dzisiejszych czasach to robią, na bieżąco swapują
sektory, jeśli któryś sektor "leży" z zapisanymi danymi za długo i
potrzebuje za dużo ECC (korekcji błędów), aby w ogóle zostać
odczytany, to zostaje nadpisany ponownie/zwolniony z użytku itd.

To świetnie. Czy w ssd też jest tak, że jest jakaś pula komórek(bad sectorów), które mogą być do wyczerpania tej puli podmienione?
A propos bad sectorów i smart. Nadal nie wiem, czy jeśli dysk hdd raportuje realokowane sektory, to znaczy, że ta niewidoczna pula zapasowych się wyczerpała, czy każde takie zdarzenie. To nie jest takie pewne, bo chyba nawet jak Smart pokazuje realokację, to bywa że pełny skan dysku jest czysty i nie pokazuje badów.

HDD raportuje reallokowane sektory zawsze, bez względu na ich ilość, sektorów zapasowych
może być kilka tysięcy, sektory złe zapisane są w dwóch tabelach, fabrycznie złe, które
pojawiły się w czasie produkcji i w drugiej te, które wysiadły w czasie eksploatacji u
usera.
Translator sięga do tych tabel i podstawia adresy dobrych sektorów przy
zapisie/odczycie(jeśli wystąpiła reallokacja i sektor jest przeadresowany, to te tabele
zawierają adresy fizycznego sektora złego i adres odpowiadającego mu sektora z puli
zapasowej).
Wszystko to jest sporym uproszczeniem, bo sprawa nie jest tak prosta, firmware dysku HDD
czy SSD to często kawał skomplikowanego kodu.
--
Gdyby się wysadziło ich planety, zburzyło miasta,
spaliło księgi, a ich samych wytłukło do nogi,
może udałoby się ocalić naukę miłości bliźniego. SL.

On 2020-07-10, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid> wrote:

HDD raportuje reallokowane sektory zawsze, bez względu na ich ilość, sektorów zapasowych może być kilka tysięcy, sektory złe zapisane są w dwóch tabelach, fabrycznie złe, które pojawiły się w czasie produkcji i w drugiej te, które wysiadły w czasie eksploatacji u usera. Translator sięga do tych tabel i podstawia adresy dobrych sektorów przy zapisie/odczycie(jeśli wystąpiła reallokacja i sektor jest przeadresowany, to te tabele zawierają adresy fizycznego sektora złego i adres odpowiadającego mu sektora z puli zapasowej). Wszystko to jest sporym uproszczeniem, bo sprawa nie jest tak prosta, firmware dysku HDD czy SSD to często kawał skomplikowanego kodu.

Jakim narzędziem, najchętniej pod Linuxem, można podejrzeć takie tabele, szczególnie tę fabryczną? --
Marcin

Wcale nie przypadkiem, dnia Sat, 11 Jul 2020 01:11:18 GMT  doszła do mnie wiadomość  <Wk8OG.62856$YW4.42897@fx23.ams1>  od Marcin Debowski <agatek@INVALID.zoho.com>  :

On 2020-07-10, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid> wrote:

HDD raportuje reallokowane sektory zawsze, bez względu na ich ilość, sektorów zapasowych może być kilka tysięcy, sektory złe zapisane są w dwóch tabelach, fabrycznie złe, które pojawiły się w czasie produkcji i w drugiej te, które wysiadły w czasie eksploatacji u usera. Translator sięga do tych tabel i podstawia adresy dobrych sektorów przy zapisie/odczycie(jeśli wystąpiła reallokacja i sektor jest przeadresowany, to te tabele zawierają adresy fizycznego sektora złego i adres odpowiadającego mu sektora z puli zapasowej). Wszystko to jest sporym uproszczeniem, bo sprawa nie jest tak prosta, firmware dysku HDD czy SSD to często kawał skomplikowanego kodu.

Jakim narzędziem, najchętniej pod Linuxem, można podejrzeć takie tabele, szczególnie tę fabryczną?

PC-3000 lub coś podobnego, czyli soft+hardware, zdaje się, że w dyskach Seagate można
przez terminal w trybie serwisowym, dawno się tym nie zajmowałem, więc moje informacje
mogą być mało warte.
--
Gdyby się wysadziło ich planety, zburzyło miasta,
spaliło księgi, a ich samych wytłukło do nogi,
może udałoby się ocalić naukę miłości bliźniego. SL.

Witaj Olaf Frikiov Skiorvensen, 11 lip 2020 w
news:d3tjgfhfpr3ekol9d9k54g9mcv0bhi3i1d4ax.com napisałeś/aś:

Wcale nie przypadkiem, dnia Sat, 11 Jul 2020 01:11:18 GMT  doszła do mnie wiadomość  <Wk8OG.62856$YW4.42897@fx23.ams1>  od Marcin Debowski <agatek@INVALID.zoho.com>  :

On 2020-07-10, Olaf Frikiov Skiorvensen <Belzebub@invalid.invalid>
wrote:

HDD raportuje reallokowane sektory zawsze, bez względu na ich
ilość, sektorów zapasowych może być kilka tysięcy, sektory złe
zapisane są w dwóch tabelach, fabrycznie złe, które pojawiły się w
czasie produkcji i w drugiej te, które wysiadły w czasie
eksploatacji u usera. Translator sięga do tych tabel i podstawia

No właśnie, gdzieś na forum przeczytałem, że to normalne w przypadku ssd, że nowy dysk ma na starcie po otwarciu pudełka raportowane w smart jakąś niedużą liczbę badbloków.

Jakim narzędziem, najchętniej pod Linuxem, można podejrzeć takie
tabele, szczególnie tę fabryczną?

PC-3000 lub coś podobnego, czyli soft+hardware, zdaje się, że w
dyskach Seagate można przez terminal w trybie serwisowym, dawno się
tym nie zajmowałem, więc moje informacje mogą być mało warte.

A może wiesz, czy gdzieś można znaleźć soft do odczytywania informacji o kontrolerze, pamięci, który jest kompatybilny z Marvellem? Znalazłem na http://allssd.ru/kak_opredelit_tip_nand_flash/
jakieś narzędzia, ale są tylko do Phison, Silicon, SandForce

Wcale nie przypadkiem, dnia Fri, 10 Jul 2020 16:42:59 +0100  doszła do mnie wiadomość  <rea2a3$8a1$1$pioruns@news.chmurka.net>  od pioruns <www@website.com>  :

Hi,

Poruszyłeś fajny temat - rzeka :) Mogę się mylić co do niektórych
rzeczy, to jak coś to mnie poprawiajcie.

On 10/07/2020 15:48, pueblo wrote:

Wiem, że z technicznych powodów nie powinno się zapełniać SSD w całości. Zresztą system na pełnym hdd też będzie miał problemy.

HDD mechaniczny "nie rozumie" zajętości i go to zupełnie nie obchodzi -
dane są przechowywane cały czas i wszędzie, czy to w wolnych sektorach
czy zajętych. Możesz mieć HDD zapełniony w 100% i jego to nie boli.

Dyski SMR rozumieją, czasem muszą się przebudowywać niemal jak SSD.
https://pl.wikipedia.org/wiki/Shingled_magnetic_recording
Co do SSD, dobrym zwyczajem jest pozostawienie pewnej ilości wolnego miejsca poza
partycjami(10-20%), co powiększa pulę OP.
https://www.kingston.com/pl/ssd/overprovisioning --
Gdyby się wysadziło ich planety, zburzyło miasta,
spaliło księgi, a ich samych wytłukło do nogi,
może udałoby się ocalić naukę miłości bliźniego. SL.

On 10/07/2020 18:04, Olaf Frikiov Skiorvensen wrote:

HDD mechaniczny "nie rozumie" zajętości i go to zupełnie nie obchodzi -
dane są przechowywane cały czas i wszędzie, czy to w wolnych sektorach
czy zajętych. Możesz mieć HDD zapełniony w 100% i jego to nie boli.

Dyski SMR rozumieją, czasem muszą się przebudowywać niemal jak SSD.
https://pl.wikipedia.org/wiki/Shingled_magnetic_recording
Co do SSD, dobrym zwyczajem jest pozostawienie pewnej ilości wolnego miejsca poza
partycjami(10-20%), co powiększa pulę OP.
https://www.kingston.com/pl/ssd/overprovisioning

Bardzo ciekawe spostrzeżenie :)
Dyski SMR powoli wypierają zwykłe, ale jeśli ktoś takiego nie ma, to dla
niego to stwierdzenie, że dyski HDD nie dbają na poziom zajętości
filesystemów na danym dysku i ich nic nie boli jak są zajęte w całości,
 jest prawdziwe.

--
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

Boli, i to bardzo.


-- -- -

Możesz mieć HDD zapełniony w 100% i jego to nie boli.

On 10/07/2020 20:16, ąćęłńóśźż wrote:

Boli, i to bardzo.


-- -- -

Możesz mieć HDD zapełniony w 100% i jego to nie boli.

Mylisz się, nie boli, HDD nie obchodzi co jest na nim nagrane. Może być
nagrany output z /dev/urandom na całej powierzchni dysku i on się od
tego nie zużywa. A SSD się zużywa, gdybyś partycję założył i zostawił ją
w 100% zajętą, no to byłby problem dla wear levelingu i żywotności
komórek, bo kontroler by panikował mając *wszystkie* komórki (oprócz
niewidocznego overprovisioningu) zajęte, trzeba im trzymać napięcie i
poziom odczytywalności na przyzwoitym (poprzez kontrolę ilości korekt ECC).

Dyski HDD, wszystkie od lat 80' aż do teraz - oprócz dysków SMR jak
wymienił Olaf Frikiov Skiorvensen, nie interesują się co jest nagrane na
powierzchni talerzy, czy są tam zera, jedynki, czy zajęte w filesystemie
czy wolne.

--
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

Bzdura.
Przykładowo serwery sobie w tle robią "porządki" na dysku.
I jest cholerną różnicą, czy wolnego jest 50% czy 5%.
To tak jakbyś wszedł do pustego mieszkania lub do sklepu pełnego porcelany.


-- -- -

Dyski HDD, wszystkie od lat 80' aż do teraz nie interesują się co jest nagrane na powierzchni talerzy, czy są tam zera, jedynki, czy zajęte w filesystemie czy wolne.

W dniu 2020-07-11 o 09:24, ąćęłńóśźż pisze:

Bzdura.
Przykładowo serwery sobie w tle robią "porządki" na dysku.

Bzdura,
robią tylko defragmentację w tle aby był szybszy odczyt danych a nie sprawdzają czy namagnesować czy nie. I defragmentację wali czy ma 99% zajęte czy 50%, odczyt sektorów jest na takim samym poziomie.

dla SSD defragmentacja nie potrzebna bo głowicy latającej z punktu do punktu nie ma. Za to jest walka o operacje blokowe, ilość ich wykonania na komórkach oraz równomierność ich wykonania (ilość zapisów) na całej powierzchni, co ma już wpływ na szybkość odczytu sektorów.

Zupełnie inny mechanizm.

--
Irokez

Bzdura.
Napisz algorytm, to się przekonasz.
Lub użyj czasomierza (stoper vs. kalendarz).


-- -- -

defragmentację wali czy ma 99% zajęte czy 50%

W dniu 2020-07-11 o 14:30, ąćęłńóśźż pisze:

Bzdura.
Napisz algorytm, to się przekonasz.
Lub użyj czasomierza (stoper vs. kalendarz).

ale że co?
twierdzisz, że prędkość odczytu sektora HDD zwiększa się wraz z zapełnieniem (pomijam odległość od środka talerzy)?

Bo to że defragmentacja dla 1TB zajętego w połowie (500GB do poukładania) jest czasowo szybsza niż zajętego w 99% (990GB do poukładania plus trochę więcej żeźby) to chyba normalne.



--
Irokez

Defragmentacja 1 TB zajętego w połowie (500 GB) będzie szybsza niż defragmentacja 500 GB zajętego w 95%.


-- -- -

Bo to że defragmentacja dla 1TB zajętego w połowie jest czasowo szybsza niż zajętego w 99% to chyba normalne.

On 11/07/2020 08:24, ąćęłńóśźż wrote:

Bzdura.
Przykładowo serwery sobie w tle robią "porządki" na dysku.
I jest cholerną różnicą, czy wolnego jest 50% czy 5%.
To tak jakbyś wszedł do pustego mieszkania lub do sklepu pełnego porcelany.


-- -- -

Dyski HDD, wszystkie od lat 80' aż do teraz nie interesują się co jest
nagrane na powierzchni talerzy, czy są tam zera, jedynki, czy zajęte w
filesystemie czy wolne.

Nie odróżniasz problemów filesystemu (serwer coś tam sobie w tle robi)
od fizycznej alokacji sektorów na dysku, o które HDD nie dba - on cały
czas przechowuje dane na powierzchni magnetycznej i ma w nosie, czy Ty
tam masz bazy danych, same zera czy słit fotki.
HDD to cegła, cegła nie dba czy jest w domu, czy na palecie jeszcze
leży. Dopiero mieszkanie (filesystem) jest zbudowane z tych cegieł i
wtedy Cię interesuje ułożenie cegieł (pokoje, pliki) i korytarze (puste
przestrzenie między plikami, aby można było wnieść większe meble).
Ale cegła czyli HDD tego nie interesuje, rozumiesz?

--
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

Chyba rozmawiamy o czymś innym.
Mnie wali, czy w wolnych sektorach są zapisane zera czy jedynki czy ćwiartki.
Ale dla sprawności działania systemu jest różnica, czy wolnych sektorów na HDD jest 50% czy 5%.


-- -- -

Ale cegła czyli HDD tego nie interesuje

W dniu 2020-07-11 o 14:35, ąćęłńóśźż pisze:

Chyba rozmawiamy o czymś innym.
Mnie wali, czy w wolnych sektorach są zapisane zera czy jedynki czy ćwiartki.
Ale dla sprawności działania systemu jest różnica, czy wolnych sektorów na HDD jest 50% czy 5%.

System wali czy ma 50% czy 5% i działa tak samo sprawnie, do momentu gdy napotka problem typu "zabrakło miejsca na pagefile"


--
Irokez

HDD nie wali, czy ma 50% czy 5% i nie działa tak samo sprawnie.


-- -- -

System wali czy ma 50% czy 5% i działa tak samo sprawnie

W dniu 2020-07-11 o 19:58, ąćęłńóśźż pisze:

HDD nie wali, czy ma 50% czy 5% i nie działa tak samo sprawnie.

pokaż mi dysk HDD, w którym po zapełnieniu do połowy, prędkość zapisu leci Ci ponad 60% w dół tak jak w ADATA SU650:
https://whatnext.pl/dysk-ssd-zwalnia-zapelnieniu/4/


--
Irokez

On 11/07/2020 18:58, ąćęłńóśźż wrote:

HDD nie wali, czy ma 50% czy 5% i nie działa tak samo sprawnie.

Znowu nie odróżniasz logicznego systemu plików od fizycznego urządzenia
(Hard Disk Drive, czyli metalowy pojemnik z talerzami w środku).

HDD nie rozumie filesystemów i nie musi, bo pamięta WSZYSTKO jak leci, i
go to wali czy ma partycje, filesystemy, a może nic nie ma

SSD rozumie filesystemy i korzysta z miejsca, które filesystem oznacza
jako wolne, aby wykonywać swoje zapisy, bo inaczej ma lipe z wear
levelingiem

Rozumiesz, czy już nie ma nadziei?

--
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

Wiesz, mnie już wali czy Ty rozumiesz co to są głowica, ścieżka, talerz i skakanie po nich i jaka jest różnica pomiędzy zapełnieniem HDD 1TB w 50%, a zapełnieniem HDD 500GB w 95%...
Możesz zapełnić swoje HDD w swoich PC (lub w swoich NAS) w 95% i przekonać, jak Ci idzie praca.


-- -- -

Znowu nie odróżniasz logicznego systemu plików od fizycznego urządzenia.
HDD nie rozumie filesystemów i nie musi, bo pamięta WSZYSTKO jak leci, i go to wali czy ma partycje, filesystemy, a może nic nie ma

On 12/07/2020 18:37, ąćęłńóśźż wrote:

Wiesz, mnie już wali czy Ty rozumiesz co to są głowica, ścieżka, talerz
i skakanie po nich i jaka jest różnica pomiędzy zapełnieniem HDD 1TB w
50%, a zapełnieniem HDD 500GB w 95%...
Możesz zapełnić swoje HDD w swoich PC (lub w swoich NAS) w 95% i
przekonać, jak Ci idzie praca.


-- -- -

Znowu nie odróżniasz logicznego systemu plików od fizycznego urządzenia.
HDD nie rozumie filesystemów i nie musi, bo pamięta WSZYSTKO jak leci,
i go to wali czy ma partycje, filesystemy, a może nic nie ma

hahaha... Niereformowalny.
Nie odróżniasz sprzętu od software, no cóż, nie mój problem.

--
pozdrawiam,   pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644

W dniu 12.07.2020 o 19:37, ąćęłńóśźż pisze:

Wiesz, mnie już wali czy Ty rozumiesz co to są głowica, ścieżka, talerz i skakanie po nich i jaka jest różnica pomiędzy zapełnieniem HDD 1TB w 50%, a zapełnieniem HDD 500GB w 95%...
Możesz zapełnić swoje HDD w swoich PC (lub w swoich NAS) w 95% i przekonać, jak Ci idzie praca.


-- -- -

Znowu nie odróżniasz logicznego systemu plików od fizycznego urządzenia.
HDD nie rozumie filesystemów i nie musi, bo pamięta WSZYSTKO jak leci, i go to wali czy ma partycje, filesystemy, a może nic nie ma

Oboje opisujecie podobne kwestie, ale z innej perspektywy i w konsekwencji widać to i owo nieco inaczej. Jednak tak czy siak oboje macie rację. Nie ma o co się spierać. :)
https://i.pinimg.com/originals/79/69/00/7969003a49be87b104b5afcfbc5b4afb.gif