Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
przywracanie fabrycznej wielkości partycji na pendrive-je, reset do stanu fabrycznego, różne wyniki formatowania
836 views
Skip to first unread message
gienek
Jan 22, 2018, 4:03:07 PM1/22/18
to
Po zabawach z rufus-em
https://rufus.akeo.ie/ i tworzeniu nim na penie partycji boot-owalnych, nie
znalazłem narzędzia, które przywraca taką samą pojemność partycji, jaką pen
miał gdy wyjęło się go jako nowego z blistra.
I tak pen 16GB jako nówka (czyli dziewiczy wyciągnięty z blistra) miał
rozmiar partycji:
15 623 790 592 Bajtów
Gdy ukończono zabawę pena z programem rufus, sformatowałem go także rufusem
(by usunąć śmieci po zabawach z bootowanymi partycjami) i wyszło z tego, że
pen uzyskał nowy rozmiar partycji:
15 622 766 592 Bajtów, czyli zniknęło gdzieś 1MB rozmiaru.
Przemielenie tego pena programem Bootice zgodnie z przepisem
https://danowski.pl/przywracanie-pamieci-pendrive-do-oryginalnego-stanu/
pozostawia ten "nowy" rozmiar 15 622 766 592 Bajtów bez zmian na wynikowej
partycji.
Potem przemieliłem ten pen programem HDD LLF Low Level Format Tool
http://hddguru.com/software/HDD-LLF-Low-Level-Format-Tool/
i nagle nastąpiło dziwne cudowne rozmnożenie.
Po założeniu partycji pod win z takimi samymi parametrami jak fabryczna
FAT32, klaster 8192KB wyszło z tego:
15 625 314 304 Bajtów
Czyli przybyło prawie 2MB względem fabrycznego rozmiaru. Ten program ma
jakąś taką właśnie tendencję do poszerzenia obszaru, który potem system
zakładający nową partycję może sobie wziąć z pamięci.
Gdzie tu sens? Każdy program rezerwuje inne obszary danych? Chyba
rozmnożenie partycji o 2MB nie jest dobre? Bo zabiera pewnie jakiś rezerwowy
obszar pamięci.
Z tego co pamiętam przy zabawach HDDLLF innymi pendrive-ami jak wykonywało
się kolejne formatowanie pena jeszcze raz programem HDD LLF Low Level Format
Tool to znów partycja powiększała się. Nie chciałem przeprowadzać kolejnych
prób, bo by się okazało, że przybędzie za chwilę po n-tej próbie i 20MB, ale
przecież nie o to tu chodzi.
Czy nie ma programu, który przywraca do co Bajta to co fabryka wypuściła?
Każdy pen musiałby mieć jakiś dedykowany soft producenta do resetowania?
https://rufus.akeo.ie/ i tworzeniu nim na penie partycji boot-owalnych, nie
znalazłem narzędzia, które przywraca taką samą pojemność partycji, jaką pen
miał gdy wyjęło się go jako nowego z blistra.
I tak pen 16GB jako nówka (czyli dziewiczy wyciągnięty z blistra) miał
rozmiar partycji:
15 623 790 592 Bajtów
Gdy ukończono zabawę pena z programem rufus, sformatowałem go także rufusem
(by usunąć śmieci po zabawach z bootowanymi partycjami) i wyszło z tego, że
pen uzyskał nowy rozmiar partycji:
15 622 766 592 Bajtów, czyli zniknęło gdzieś 1MB rozmiaru.
Przemielenie tego pena programem Bootice zgodnie z przepisem
https://danowski.pl/przywracanie-pamieci-pendrive-do-oryginalnego-stanu/
pozostawia ten "nowy" rozmiar 15 622 766 592 Bajtów bez zmian na wynikowej
partycji.
Potem przemieliłem ten pen programem HDD LLF Low Level Format Tool
http://hddguru.com/software/HDD-LLF-Low-Level-Format-Tool/
i nagle nastąpiło dziwne cudowne rozmnożenie.
Po założeniu partycji pod win z takimi samymi parametrami jak fabryczna
FAT32, klaster 8192KB wyszło z tego:
15 625 314 304 Bajtów
Czyli przybyło prawie 2MB względem fabrycznego rozmiaru. Ten program ma
jakąś taką właśnie tendencję do poszerzenia obszaru, który potem system
zakładający nową partycję może sobie wziąć z pamięci.
Gdzie tu sens? Każdy program rezerwuje inne obszary danych? Chyba
rozmnożenie partycji o 2MB nie jest dobre? Bo zabiera pewnie jakiś rezerwowy
obszar pamięci.
Z tego co pamiętam przy zabawach HDDLLF innymi pendrive-ami jak wykonywało
się kolejne formatowanie pena jeszcze raz programem HDD LLF Low Level Format
Tool to znów partycja powiększała się. Nie chciałem przeprowadzać kolejnych
prób, bo by się okazało, że przybędzie za chwilę po n-tej próbie i 20MB, ale
przecież nie o to tu chodzi.
Czy nie ma programu, który przywraca do co Bajta to co fabryka wypuściła?
Każdy pen musiałby mieć jakiś dedykowany soft producenta do resetowania?
Olaf Frikiov Skiorvensen
Jan 22, 2018, 5:08:01 PM1/22/18
to
Wcale nie przypadkiem, dnia Mon, 22 Jan 2018 22:03:04 +0100
doszła do mnie wiadomość <dks9C.314920$fg4.3...@fx08.am4>
od "gienek" <niel...@sp.amu> :
>Czy nie ma programu, który przywraca do co Bajta to co fabryka wypuściła?
>Każdy pen musiałby mieć jakiś dedykowany soft producenta do resetowania?
Mam pewną radę, olej to, zapomnij o "przywracaniu fabrycznej pojemności" i poczytaj
specjalistów w tej dziedzinie:
https://github.com/bradfa/flashbench
Partycjonuj tak, aby początek partycji wypadał w LBA 8192, tak lubi większość pamięci
flash(align to erase block size).
Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście MB), i to w
zasadzie wszystko co można zrobić.
Jeśli jednak chcesz się pobawić w ustalanie optymalnego początku partycji, to flashbench
będzie niezastąpiony.
--
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.
doszła do mnie wiadomość <dks9C.314920$fg4.3...@fx08.am4>
od "gienek" <niel...@sp.amu> :
>Czy nie ma programu, który przywraca do co Bajta to co fabryka wypuściła?
>Każdy pen musiałby mieć jakiś dedykowany soft producenta do resetowania?
specjalistów w tej dziedzinie:
https://github.com/bradfa/flashbench
Partycjonuj tak, aby początek partycji wypadał w LBA 8192, tak lubi większość pamięci
flash(align to erase block size).
Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście MB), i to w
zasadzie wszystko co można zrobić.
Jeśli jednak chcesz się pobawić w ustalanie optymalnego początku partycji, to flashbench
będzie niezastąpiony.
--
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.
Marcin Debowski
Jan 22, 2018, 5:17:42 PM1/22/18
to
On 2018-01-22, Olaf Frikiov Skiorvensen <Belz...@invalid.invalid> wrote:
> Mam pewną radę, olej to, zapomnij o "przywracaniu fabrycznej pojemności" i poczytaj
> specjalistów w tej dziedzinie:
> https://github.com/bradfa/flashbench
> Partycjonuj tak, aby początek partycji wypadał w LBA 8192, tak lubi większość pamięci
> flash(align to erase block size).
> Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście MB), i to w
> zasadzie wszystko co można zrobić.
> Jeśli jednak chcesz się pobawić w ustalanie optymalnego początku partycji, to flashbench
> będzie niezastąpiony.
Na ile różnice w początku partycji są istotne i jak to się w praktyce
> Mam pewną radę, olej to, zapomnij o "przywracaniu fabrycznej pojemności" i poczytaj
> specjalistów w tej dziedzinie:
> https://github.com/bradfa/flashbench
> Partycjonuj tak, aby początek partycji wypadał w LBA 8192, tak lubi większość pamięci
> flash(align to erase block size).
> Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście MB), i to w
> zasadzie wszystko co można zrobić.
> Jeśli jednak chcesz się pobawić w ustalanie optymalnego początku partycji, to flashbench
> będzie niezastąpiony.
manifestuje?
--
Marcin
Olaf Frikiov Skiorvensen
Jan 23, 2018, 3:06:03 AM1/23/18
to
Wcale nie przypadkiem, dnia Mon, 22 Jan 2018 22:17:40 GMT
doszła do mnie wiadomość <8qt9C.37425$UH3....@fx16.ams1>
od Marcin Debowski <aga...@INVALID.zoho.com> :
W praktyce mogą to być spadki wydajności(przycięcia), rośnie write amplification(flash
szybciej expiruje, zapis jednego klastra powoduje, że garbage collector musi przewalić
megabajty danych), do tego dochodzi brak TRIM(na flashu mamy masę śmieci, które kontroler
musi jakoś obsługiwać):
https://en.wikipedia.org/wiki/Write_amplification
https://lwn.net/Articles/428584/
Typowy user nic niepokojącego nie zauważy, za to może szybciej wykończyć flasha.
Moim zdaniem, warto sobie przyjąć tak:
- na nośnikach flash zaczynamy partycję od sektora 8192(a nawet 16384)
- zawsze zostawiamy tak z 10% niespartycjonowanego miejsca(zwiększamy OP), ale to raczej w
nowych nośnikach(z pudełka)
- dla dysków mechanicznych w zasadzie można tak samo(wystarczy, że numer LBA początku
partycji będzie podzielny przez 8)
Poza tym dzięki temu zawsze wiemy, gdzie był początek partycji(przydatne przy odzyskiwaniu
danych)
doszła do mnie wiadomość <8qt9C.37425$UH3....@fx16.ams1>
od Marcin Debowski <aga...@INVALID.zoho.com> :
szybciej expiruje, zapis jednego klastra powoduje, że garbage collector musi przewalić
megabajty danych), do tego dochodzi brak TRIM(na flashu mamy masę śmieci, które kontroler
musi jakoś obsługiwać):
https://en.wikipedia.org/wiki/Write_amplification
https://lwn.net/Articles/428584/
Typowy user nic niepokojącego nie zauważy, za to może szybciej wykończyć flasha.
Moim zdaniem, warto sobie przyjąć tak:
- na nośnikach flash zaczynamy partycję od sektora 8192(a nawet 16384)
- zawsze zostawiamy tak z 10% niespartycjonowanego miejsca(zwiększamy OP), ale to raczej w
nowych nośnikach(z pudełka)
- dla dysków mechanicznych w zasadzie można tak samo(wystarczy, że numer LBA początku
partycji będzie podzielny przez 8)
Poza tym dzięki temu zawsze wiemy, gdzie był początek partycji(przydatne przy odzyskiwaniu
danych)
m4rkiz
Jan 23, 2018, 3:16:34 AM1/23/18
to
On 2018-01-22 22:03, gienek wrote:
> Po zabawach z rufus-em
> https://rufus.akeo.ie/ i tworzeniu nim na penie partycji boot-owalnych, nie
> znalazłem narzędzia, które przywraca taką samą pojemność partycji, jaką pen
> miał gdy wyjęło się go jako nowego z blistra.
> I tak pen 16GB jako nówka (czyli dziewiczy wyciągnięty z blistra) miał
> rozmiar partycji:
> 15 623 790 592 Bajtów
> Gdy ukończono zabawę pena z programem rufus, sformatowałem go także rufusem
> (by usunąć śmieci po zabawach z bootowanymi partycjami) i wyszło z tego, że
> pen uzyskał nowy rozmiar partycji:
> 15 622 766 592 Bajtów, czyli zniknęło gdzieś 1MB rozmiaru.
z tego co mi sie kojarzy to roznica w rozmiarze moze polegac na
> Po zabawach z rufus-em
> https://rufus.akeo.ie/ i tworzeniu nim na penie partycji boot-owalnych, nie
> znalazłem narzędzia, które przywraca taką samą pojemność partycji, jaką pen
> miał gdy wyjęło się go jako nowego z blistra.
> I tak pen 16GB jako nówka (czyli dziewiczy wyciągnięty z blistra) miał
> rozmiar partycji:
> 15 623 790 592 Bajtów
> Gdy ukończono zabawę pena z programem rufus, sformatowałem go także rufusem
> (by usunąć śmieci po zabawach z bootowanymi partycjami) i wyszło z tego, że
> pen uzyskał nowy rozmiar partycji:
> 15 622 766 592 Bajtów, czyli zniknęło gdzieś 1MB rozmiaru.
istnieniu badz nie tablicy partycji - pendrive oryginalnie mogl jej nie
posiadac ale nic nie dam sobie za to twierdzenie uciac a szukac
szczegolow mi sie nie chce :P
knrdz
Jan 23, 2018, 11:18:21 AM1/23/18
to
W dniu 23.01.2018 o 09:05, Olaf Frikiov Skiorvensen pisze:
> - zawsze zostawiamy tak z 10% niespartycjonowanego miejsca(zwiększamy OP), ale to raczej w
> nowych nośnikach(z pudełka)
Jaki to ma sens? Nie lepiej po prostu starać się mieć zawsze te 10-20%
wolnego miejsca (łącznie, na wszystkich partycjach danego ssd), wyjdzie
na to samo, a w razie chwilowej potrzeby ma się dostęp do 100%
pojemności, a nie 90%.
> - zawsze zostawiamy tak z 10% niespartycjonowanego miejsca(zwiększamy OP), ale to raczej w
> nowych nośnikach(z pudełka)
wolnego miejsca (łącznie, na wszystkich partycjach danego ssd), wyjdzie
na to samo, a w razie chwilowej potrzeby ma się dostęp do 100%
pojemności, a nie 90%.
m
Jan 23, 2018, 11:55:16 AM1/23/18
to
W dniu 23.01.2018 o 17:18, knrdz pisze:
Taki sam jaki posiadanie osobno otwieranej rezerwy w butlach do
nurkowania. W razie potrzeby, otwieramy rezerwy i na tej rezerwie się
ekspresikiem wynurzamy (ewentualnie - organizujemy sobie powietrze na
dłuższe wynurzanie).
Jak masz 100% zajętości dysku, to czasem nawet coś zwolnić na gwałt.
p. m.
nurkowania. W razie potrzeby, otwieramy rezerwy i na tej rezerwie się
ekspresikiem wynurzamy (ewentualnie - organizujemy sobie powietrze na
dłuższe wynurzanie).
Jak masz 100% zajętości dysku, to czasem nawet coś zwolnić na gwałt.
p. m.
knrdz
Jan 23, 2018, 1:55:30 PM1/23/18
to
W dniu 23.01.2018 o 17:55, m pisze:
> Taki sam jaki posiadanie osobno otwieranej rezerwy w butlach do
> nurkowania. W razie potrzeby, otwieramy rezerwy i na tej rezerwie się
> ekspresikiem wynurzamy (ewentualnie - organizujemy sobie powietrze na
> dłuższe wynurzanie).
>
> Jak masz 100% zajętości dysku, to czasem nawet coś zwolnić na gwałt.
Nie jestem nurkiem i nie wiem czy taka rezerwowa butla to konieczność,
ale dodatkowy overprovisioning utworzony z przestrzeni użytkowej we
współczesnych ssd wydaje się grubą przesadą. Może jak konfigurujemy
komputer dla jakiejś osoby, która nie rozumie że powinna mieć ileś tam
wolnego miejsca (i w tym celu wystarczy co jakiś czas usunąć stare
niepotrzebne pliki), ale normalny użytkownik potrafi dopilnować by nigdy
nie mieć dysku zapchanego "pod korek". A lepiej mieć dodatkowe miejsce
dostępne w razie potrzeby (np. na pliki tymczasowe - choćby microsoftowy
windows media creation tool wymaga przez chwilę 2 razy więcej miejsca na
partycji systemowej niż docelowo zajmuje pobrany przez niego obraz), niż
takie z którego skorzystać się nie da.
> Taki sam jaki posiadanie osobno otwieranej rezerwy w butlach do
> nurkowania. W razie potrzeby, otwieramy rezerwy i na tej rezerwie się
> ekspresikiem wynurzamy (ewentualnie - organizujemy sobie powietrze na
> dłuższe wynurzanie).
>
> Jak masz 100% zajętości dysku, to czasem nawet coś zwolnić na gwałt.
ale dodatkowy overprovisioning utworzony z przestrzeni użytkowej we
współczesnych ssd wydaje się grubą przesadą. Może jak konfigurujemy
komputer dla jakiejś osoby, która nie rozumie że powinna mieć ileś tam
wolnego miejsca (i w tym celu wystarczy co jakiś czas usunąć stare
niepotrzebne pliki), ale normalny użytkownik potrafi dopilnować by nigdy
nie mieć dysku zapchanego "pod korek". A lepiej mieć dodatkowe miejsce
dostępne w razie potrzeby (np. na pliki tymczasowe - choćby microsoftowy
windows media creation tool wymaga przez chwilę 2 razy więcej miejsca na
partycji systemowej niż docelowo zajmuje pobrany przez niego obraz), niż
takie z którego skorzystać się nie da.
m
Jan 23, 2018, 5:18:47 PM1/23/18
to
W dniu 23.01.2018 o 19:55, knrdz pisze:
Nie wiem na ile odbiegam od normy, ale zdarzyło mi się kilka razy że
logi niespodziewanie urosły, zajęły dysk pod korek, praca którą miałem
otwartą (w programie który tak zaczął srać logami) - nie chciała się
zapisać, nie miałem żadnych danych które mógłbym bez żalu skasować.
Wprost błogosławiłem fakt że miałem w odwodzie kilka GB wolnego miejsca
na grupie LVM, zwiększyłem filesystem, spakowałem kilka większych
plików, zapisałem pracę i mogłem się poświęcić dokładniejszym porządkom
na dysku, a przede wszystkim ubić program który srał logami i skasować
niepotrzebne logi.
p. m.
logi niespodziewanie urosły, zajęły dysk pod korek, praca którą miałem
otwartą (w programie który tak zaczął srać logami) - nie chciała się
zapisać, nie miałem żadnych danych które mógłbym bez żalu skasować.
Wprost błogosławiłem fakt że miałem w odwodzie kilka GB wolnego miejsca
na grupie LVM, zwiększyłem filesystem, spakowałem kilka większych
plików, zapisałem pracę i mogłem się poświęcić dokładniejszym porządkom
na dysku, a przede wszystkim ubić program który srał logami i skasować
niepotrzebne logi.
p. m.
Marcin Debowski
Jan 23, 2018, 7:29:08 PM1/23/18
to
On 2018-01-23, m <mvo...@gmail.com> wrote:
> Nie wiem na ile odbiegam od normy, ale zdarzyło mi się kilka razy że
> logi niespodziewanie urosły, zajęły dysk pod korek, praca którą miałem
> otwartą (w programie który tak zaczął srać logami) - nie chciała się
> zapisać, nie miałem żadnych danych które mógłbym bez żalu skasować.
> Wprost błogosławiłem fakt że miałem w odwodzie kilka GB wolnego miejsca
> na grupie LVM, zwiększyłem filesystem, spakowałem kilka większych
No ale czym, poza większą upierdliwością, będzie się to różniło od
> Nie wiem na ile odbiegam od normy, ale zdarzyło mi się kilka razy że
> logi niespodziewanie urosły, zajęły dysk pod korek, praca którą miałem
> otwartą (w programie który tak zaczął srać logami) - nie chciała się
> zapisać, nie miałem żadnych danych które mógłbym bez żalu skasować.
> Wprost błogosławiłem fakt że miałem w odwodzie kilka GB wolnego miejsca
> na grupie LVM, zwiększyłem filesystem, spakowałem kilka większych
wsadzenie w jakies gniazdo dysku zewnetrznego i zapisanie na nim?
To takie trochę robienie sobie najpierw pod górkę, zeby potem
ewentualnie móc skorzystac, a przeciez jakbys nie miał tej rezerwy, to
może w ogóle nie byłoby problemu. Pomijam fakt, że większość
współczesnych systemów wręcz pluje informacjami o braku miejsca na
dysku, więc jest czas aby zareagować.
> plików, zapisałem pracę i mogłem się poświęcić dokładniejszym porządkom
> na dysku, a przede wszystkim ubić program który srał logami i skasować
> niepotrzebne logi.
--
Marcin
Marcin Debowski
Jan 23, 2018, 8:38:12 PM1/23/18
to
On 2018-01-23, Olaf Frikiov Skiorvensen <Belz...@invalid.invalid> wrote:
> https://en.wikipedia.org/wiki/Write_amplification
> https://lwn.net/Articles/428584/
Dzieki. Sporo mi sie porozjaśniało. Zauważyłem, że parę lat temu fdisk
zaczą proponować początek partycji od 8192 ale nigdy nie zaciekawiło
mnie (wystarczająco) z jakiego powodu.
> - na nośnikach flash zaczynamy partycję od sektora 8192(a nawet 16384)
A rozmiar segmentu jest już w tej chwili jakoś zunifikowany, bo jeśli
będzie 16M a wystartuje z pozycji 8M to chyba będzie źle? Skoro pożądane
jest zwiększenie OP i zmiejszenie ryzyka z nietrafionym zmapowaniem
segmentów to może lepiej od razu 32768 lub nawet więcej?
--
Marcin
> https://en.wikipedia.org/wiki/Write_amplification
> https://lwn.net/Articles/428584/
Dzieki. Sporo mi sie porozjaśniało. Zauważyłem, że parę lat temu fdisk
zaczą proponować początek partycji od 8192 ale nigdy nie zaciekawiło
mnie (wystarczająco) z jakiego powodu.
> - na nośnikach flash zaczynamy partycję od sektora 8192(a nawet 16384)
będzie 16M a wystartuje z pozycji 8M to chyba będzie źle? Skoro pożądane
jest zwiększenie OP i zmiejszenie ryzyka z nietrafionym zmapowaniem
segmentów to może lepiej od razu 32768 lub nawet więcej?
--
Marcin
m
Jan 24, 2018, 5:32:48 AM1/24/18
to
W dniu 24.01.2018 o 01:29, Marcin Debowski pisze:
stosunku do kilku G rezerwy która ma się za darmo (no, za cenę lekkiego
samoograniczenia się).
>
> To takie trochę robienie sobie najpierw pod górkę, zeby potem
> ewentualnie móc skorzystac, a przeciez jakbys nie miał tej rezerwy, to
> może w ogóle nie byłoby problemu. Pomijam fakt, że większość
> współczesnych systemów wręcz pluje informacjami o braku miejsca na
> dysku, więc jest czas aby zareagować.
>
>> plików, zapisałem pracę i mogłem się poświęcić dokładniejszym porządkom
>> na dysku, a przede wszystkim ubić program który srał logami i skasować
>> niepotrzebne logi.
>
> A nie wystarczyło ubic i skasować logi? :) Porządki mogły pewnie poczekać.
Nie wystarczyło, bo logował program w którym miałem niezapisane dane.
p. m.
> On 2018-01-23, m <mvo...@gmail.com> wrote:
>> Nie wiem na ile odbiegam od normy, ale zdarzyło mi się kilka razy że
>> logi niespodziewanie urosły, zajęły dysk pod korek, praca którą miałem
>> otwartą (w programie który tak zaczął srać logami) - nie chciała się
>> zapisać, nie miałem żadnych danych które mógłbym bez żalu skasować.
>> Wprost błogosławiłem fakt że miałem w odwodzie kilka GB wolnego miejsca
>> na grupie LVM, zwiększyłem filesystem, spakowałem kilka większych
>
> No ale czym, poza większą upierdliwością, będzie się to różniło od
> wsadzenie w jakies gniazdo dysku zewnetrznego i zapisanie na nim?
Tym, że taki dysk zewnętrzny trzeba mieć. Dysk zewnętrzny jest drogi w
>> Nie wiem na ile odbiegam od normy, ale zdarzyło mi się kilka razy że
>> logi niespodziewanie urosły, zajęły dysk pod korek, praca którą miałem
>> otwartą (w programie który tak zaczął srać logami) - nie chciała się
>> zapisać, nie miałem żadnych danych które mógłbym bez żalu skasować.
>> Wprost błogosławiłem fakt że miałem w odwodzie kilka GB wolnego miejsca
>> na grupie LVM, zwiększyłem filesystem, spakowałem kilka większych
>
> No ale czym, poza większą upierdliwością, będzie się to różniło od
> wsadzenie w jakies gniazdo dysku zewnetrznego i zapisanie na nim?
stosunku do kilku G rezerwy która ma się za darmo (no, za cenę lekkiego
samoograniczenia się).
>
> To takie trochę robienie sobie najpierw pod górkę, zeby potem
> ewentualnie móc skorzystac, a przeciez jakbys nie miał tej rezerwy, to
> może w ogóle nie byłoby problemu. Pomijam fakt, że większość
> współczesnych systemów wręcz pluje informacjami o braku miejsca na
> dysku, więc jest czas aby zareagować.
>
>> plików, zapisałem pracę i mogłem się poświęcić dokładniejszym porządkom
>> na dysku, a przede wszystkim ubić program który srał logami i skasować
>> niepotrzebne logi.
>
> A nie wystarczyło ubic i skasować logi? :) Porządki mogły pewnie poczekać.
p. m.
Olaf Frikiov Skiorvensen
Jan 24, 2018, 7:27:22 AM1/24/18
to
Wcale nie przypadkiem, dnia Tue, 23 Jan 2018 17:18:18 +0100
doszła do mnie wiadomość <p47n8b$ifh$1...@node1.news.atman.pl>
od knrdz <xa...@tnmrgn.cy> :
Ja pisałem głównie o nośnikach, które nie mają TRIM(pendrive, karty SD czy coś
podobnego)ale mają wear leveling i garbage collector.
Co do SSD, TRIM spowalnia pracę(truecrypt, obsługa wielu małych plików), jak się go
wyłączy, to lepiej zrobić tak, jak pisałem - 10 czy nawet więcej (30%)
niespartycjonowanego miejsca(to zapewnia jego liniowość).
Generalnie im większy OP tym większa wydajność dysku(w przypadku spartycjonowania całości
pojawia się większa fragmentacja i spada wydajność).
Dobrym wyjściem jest trim manualny.
Linuxy mają fstrim(można wywołać z crona), defrag w w10 (z opcją /L) potrafi strimować
partycję, są programy od producentów wywołujące TRIM.
Czy takie kombinowanie ma sens?
Dla typowego usera nie ma większego sensu.
Na swoim revodrive zostawiłem 24 GiB niespartycjonowane(revo nie ma trim), często męczę
się z kartami CF i SD - tu to ma sens, widać to po wydajności(największy wpływ ma
prawidłowy align partycji, większy OP ma wpływ głównie na trwałość nośnika).
doszła do mnie wiadomość <p47n8b$ifh$1...@node1.news.atman.pl>
od knrdz <xa...@tnmrgn.cy> :
podobnego)ale mają wear leveling i garbage collector.
Co do SSD, TRIM spowalnia pracę(truecrypt, obsługa wielu małych plików), jak się go
wyłączy, to lepiej zrobić tak, jak pisałem - 10 czy nawet więcej (30%)
niespartycjonowanego miejsca(to zapewnia jego liniowość).
Generalnie im większy OP tym większa wydajność dysku(w przypadku spartycjonowania całości
pojawia się większa fragmentacja i spada wydajność).
Dobrym wyjściem jest trim manualny.
Linuxy mają fstrim(można wywołać z crona), defrag w w10 (z opcją /L) potrafi strimować
partycję, są programy od producentów wywołujące TRIM.
Czy takie kombinowanie ma sens?
Dla typowego usera nie ma większego sensu.
Na swoim revodrive zostawiłem 24 GiB niespartycjonowane(revo nie ma trim), często męczę
się z kartami CF i SD - tu to ma sens, widać to po wydajności(największy wpływ ma
prawidłowy align partycji, większy OP ma wpływ głównie na trwałość nośnika).
gienek
Jan 24, 2018, 8:55:45 AM1/24/18
to
"Olaf Frikiov Skiorvensen" news:kjnc6d5ptht6ih528...@4ax.com
Przeglądając w programie BOOTICE strukturę partycji w kilku penach widzę,
że:
ADATA S102 64GB ma początek partycji na LBA = 64
GoodRam Piccolo 16GB początek na LBA = 48
Inny GoodRam Picccolo 16GB który był po zabawach przywrócony rufusem (jego
formatowaniem) do parametrów "fabrycznych" ma teraz partycję zaczynającą się
od LBA = 2048
Czyli jak widać producenci są daleko od tego co zalecają na forum :)
Rufus wydaje się być najbliżej tego co polecane.
> Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście
> MB), i to w
> zasadzie wszystko co można zrobić.
Czym ten początek zerować?
Wchodząc w edycje sektorów i ręcznie je ustawić na zero?
> Jeśli jednak chcesz się pobawić w ustalanie optymalnego początku partycji,
> to flashbench
> będzie niezastąpiony.
O tym programie mowa?
https://helloacm.com/the-usb-flash-benchmark-tool-flashbench/
Z tego co widzę ma tylko testowanie prędkości pod kątem wielkości
zapisywanych bloków i nic więcej tu nie odnalazłem co by jakoś konfigurowało
pena.
> Partycjonuj tak, aby początek partycji wypadał w LBA 8192, tak lubi
> większość pamięci
> flash(align to erase block size).
Czemu producenci nie stosują tej zasady?
> większość pamięci
> flash(align to erase block size).
Przeglądając w programie BOOTICE strukturę partycji w kilku penach widzę,
że:
ADATA S102 64GB ma początek partycji na LBA = 64
GoodRam Piccolo 16GB początek na LBA = 48
Inny GoodRam Picccolo 16GB który był po zabawach przywrócony rufusem (jego
formatowaniem) do parametrów "fabrycznych" ma teraz partycję zaczynającą się
od LBA = 2048
Czyli jak widać producenci są daleko od tego co zalecają na forum :)
Rufus wydaje się być najbliżej tego co polecane.
> Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście
> MB), i to w
> zasadzie wszystko co można zrobić.
Wchodząc w edycje sektorów i ręcznie je ustawić na zero?
> Jeśli jednak chcesz się pobawić w ustalanie optymalnego początku partycji,
> to flashbench
> będzie niezastąpiony.
https://helloacm.com/the-usb-flash-benchmark-tool-flashbench/
Z tego co widzę ma tylko testowanie prędkości pod kątem wielkości
zapisywanych bloków i nic więcej tu nie odnalazłem co by jakoś konfigurowało
pena.
gienek
Jan 24, 2018, 9:04:44 AM1/24/18
to
"Olaf Frikiov Skiorvensen" news:sopd6d9s77mk6v498...@4ax.com
> do tego dochodzi brak TRIM(na flashu mamy masę śmieci, które kontroler
> musi jakoś obsługiwać)
TRIM to narzędzie sprzętowe w samym dysku czy raczej sam system wymusza jego
działanie. Czyli coś z gatunku konflikt win xp/win 7 gdzie ten pierwszy nie
ma tej funkcji zaszytej i w związku z tym nie zaleca się tam wsadzać SSD.
Czy do penów jest jakiś program który taką operację TRIM realizuje?
TRIM usuwa te śmieci, czy wymagane jakieś inne narzędzie które od czasu do
czasu przeczyści pena?
> - zawsze zostawiamy tak z 10% niespartycjonowanego miejsca(zwiększamy OP)
OP czy wolna przestrzeń? Ma znaczenie czy to wolne na początku czy na końcu
bloków adresowych? Czy kompletnie bez znaczenia? Ważne, że ma być wolne
niespartycjonowane miejsce.
I teraz powstaje pytanie czy te bloki LBA które widzą popularne programy
BOOTICE, DMDE to zapewne już okrojona pula, ustalona przez wewnętrzny
firmware i czy sam pen już nie ma odgórnie wewnętrznie przeprowadzonej tej
rezerwacji i pewnych bloków po prostu na zewnątrz nie widzimi programami, a
one są zaszyte w samym penie jako ta rezerwa dla szybszego działania?
> do tego dochodzi brak TRIM(na flashu mamy masę śmieci, które kontroler
> musi jakoś obsługiwać)
działanie. Czyli coś z gatunku konflikt win xp/win 7 gdzie ten pierwszy nie
ma tej funkcji zaszytej i w związku z tym nie zaleca się tam wsadzać SSD.
Czy do penów jest jakiś program który taką operację TRIM realizuje?
TRIM usuwa te śmieci, czy wymagane jakieś inne narzędzie które od czasu do
czasu przeczyści pena?
> - zawsze zostawiamy tak z 10% niespartycjonowanego miejsca(zwiększamy OP)
bloków adresowych? Czy kompletnie bez znaczenia? Ważne, że ma być wolne
niespartycjonowane miejsce.
I teraz powstaje pytanie czy te bloki LBA które widzą popularne programy
BOOTICE, DMDE to zapewne już okrojona pula, ustalona przez wewnętrzny
firmware i czy sam pen już nie ma odgórnie wewnętrznie przeprowadzonej tej
rezerwacji i pewnych bloków po prostu na zewnątrz nie widzimi programami, a
one są zaszyte w samym penie jako ta rezerwa dla szybszego działania?
Olaf Frikiov Skiorvensen
Jan 25, 2018, 3:13:50 AM1/25/18
to
Wcale nie przypadkiem, dnia Wed, 24 Jan 2018 14:55:43 +0100
doszła do mnie wiadomość <yf0aC.285798$q8.2...@fx07.am4>
od "gienek" <niel...@sp.amu> :
Ustawić początek na 8192, zapuścić jakieś testy i zapomnieć o sprawie.
więc odpalam DMDE(opcja wypełnij sektory)
https://github.com/bradfa/flashbench
W sieci sporo opisów, więc można jakoś to ogarnąć.
Jak masz sporo wolnego czasu, to możesz się bawić, ja na stałe wymuszam 8192 i po sprawie.
doszła do mnie wiadomość <yf0aC.285798$q8.2...@fx07.am4>
od "gienek" <niel...@sp.amu> :
>"Olaf Frikiov Skiorvensen" news:kjnc6d5ptht6ih528...@4ax.com
>> Partycjonuj tak, aby początek partycji wypadał w LBA 8192, tak lubi
>> większość pamięci
>> flash(align to erase block size).
>
>Czemu producenci nie stosują tej zasady?
>Przeglądając w programie BOOTICE strukturę partycji w kilku penach widzę,
>że:
>ADATA S102 64GB ma początek partycji na LBA = 64
>GoodRam Piccolo 16GB początek na LBA = 48
>Inny GoodRam Picccolo 16GB który był po zabawach przywrócony rufusem (jego
>formatowaniem) do parametrów "fabrycznych" ma teraz partycję zaczynającą się
>od LBA = 2048
>
>Czyli jak widać producenci są daleko od tego co zalecają na forum :)
>Rufus wydaje się być najbliżej tego co polecane.
Widać zdecydowali, że tak jest dobrze, ale czy optymalnie?
>> Partycjonuj tak, aby początek partycji wypadał w LBA 8192, tak lubi
>> większość pamięci
>> flash(align to erase block size).
>
>Czemu producenci nie stosują tej zasady?
>Przeglądając w programie BOOTICE strukturę partycji w kilku penach widzę,
>że:
>ADATA S102 64GB ma początek partycji na LBA = 64
>GoodRam Piccolo 16GB początek na LBA = 48
>Inny GoodRam Picccolo 16GB który był po zabawach przywrócony rufusem (jego
>formatowaniem) do parametrów "fabrycznych" ma teraz partycję zaczynającą się
>od LBA = 2048
>
>Czyli jak widać producenci są daleko od tego co zalecają na forum :)
>Rufus wydaje się być najbliżej tego co polecane.
Ustawić początek na 8192, zapuścić jakieś testy i zapomnieć o sprawie.
>
>> Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście
>> MB), i to w
>> zasadzie wszystko co można zrobić.
>
>Czym ten początek zerować?
>Wchodząc w edycje sektorów i ręcznie je ustawić na zero?
Ja robię to za pomocą DMDE/Victoria, dd pod linuxem, czasem Victoria nie chce tego zrobić
>> Przed partycjonowaniem można wyzerować początek flasha(kilka-kilkanaście
>> MB), i to w
>> zasadzie wszystko co można zrobić.
>
>Czym ten początek zerować?
>Wchodząc w edycje sektorów i ręcznie je ustawić na zero?
więc odpalam DMDE(opcja wypełnij sektory)
>> Jeśli jednak chcesz się pobawić w ustalanie optymalnego początku partycji,
>> to flashbench
>> będzie niezastąpiony.
>
>O tym programie mowa?
>https://helloacm.com/the-usb-flash-benchmark-tool-flashbench/
>Z tego co widzę ma tylko testowanie prędkości pod kątem wielkości
>zapisywanych bloków i nic więcej tu nie odnalazłem co by jakoś konfigurowało
>pena.
Myślałem o tym:
>> to flashbench
>> będzie niezastąpiony.
>
>O tym programie mowa?
>https://helloacm.com/the-usb-flash-benchmark-tool-flashbench/
>Z tego co widzę ma tylko testowanie prędkości pod kątem wielkości
>zapisywanych bloków i nic więcej tu nie odnalazłem co by jakoś konfigurowało
>pena.
https://github.com/bradfa/flashbench
W sieci sporo opisów, więc można jakoś to ogarnąć.
Jak masz sporo wolnego czasu, to możesz się bawić, ja na stałe wymuszam 8192 i po sprawie.
Olaf Frikiov Skiorvensen
Jan 25, 2018, 3:46:42 AM1/25/18
to
Wcale nie przypadkiem, dnia Wed, 24 Jan 2018 01:38:10 GMT
doszła do mnie wiadomość <6sR9C.554963$dY3.3...@fx10.ams1>
od Marcin Debowski <aga...@INVALID.zoho.com> :
Takie dane zna tylko producent, może je udostępnić albo nie.
Dla dociekliwych zostaje flashbench:
https://superuser.com/questions/728858/how-to-determine-ssds-nand-erase-block-size
Ale testy wymagają czasu czasu i rycia w internetach w poszukiwaniu rozsądnej
interpretacji wtników, więc przyjąć na stałe 8192 jest moim zdaniem optymalne w większości
przypadków.
doszła do mnie wiadomość <6sR9C.554963$dY3.3...@fx10.ams1>
od Marcin Debowski <aga...@INVALID.zoho.com> :
Dla dociekliwych zostaje flashbench:
https://superuser.com/questions/728858/how-to-determine-ssds-nand-erase-block-size
Ale testy wymagają czasu czasu i rycia w internetach w poszukiwaniu rozsądnej
interpretacji wtników, więc przyjąć na stałe 8192 jest moim zdaniem optymalne w większości
przypadków.
ń
Jan 25, 2018, 4:29:01 PM1/25/18
to
Wy ten wątek to tak serio??
Jeśli tak, to już siedemnascie postów o d... Maryni, a ani jednego o systemie plików :-o
Jeśli tak, to już siedemnascie postów o d... Maryni, a ani jednego o systemie plików :-o
Olaf Frikiov Skiorvensen
Jan 25, 2018, 6:09:00 PM1/25/18
to
Wcale nie przypadkiem, dnia Thu, 25 Jan 2018 22:29:27 +0100
doszła do mnie wiadomość <p4di6r$h4r$1...@node2.news.atman.pl>
od ń <ń@ń.ń> :
doszła do mnie wiadomość <p4di6r$h4r$1...@node2.news.atman.pl>
od ń <ń@ń.ń> :
>Wy ten wątek to tak serio??
>Jeśli tak, to już siedemnascie postów o d... Maryni, a ani jednego o systemie plików :-o
Ktoś tu pytał o system plików?
>Jeśli tak, to już siedemnascie postów o d... Maryni, a ani jednego o systemie plików :-o
0 new messages