Jeżeli lekko zmodyfikujesz plik to zmieni się w nim powiedzmy ciąg 350 bajtów. W tym przypadku na dysku zapisane zostanie zapewne 4096 bajtów (domyślny rozmiar jednostki alokacji). Przenoszenie całego pliku byłoby bez sensu i byłoby tylko "marnotrawieniem" dysku (szczególnie w przypadku kilkugigowych plików), a więc technologia służąca przedłużeniu żywotności - tylko by skracała czas jego życia. W każdym razie jak wspomniane było wyżej - raczej nie masz się czym przejmować. Przy nieserwerowym użytkowaniu dysk pożyje kilka lat - za kilka lat pewnie kupisz sobie 1TB SSD za trzy stówy ;]
0
1
Jeżeli lekko zmodyfikujesz plik to zmieni się w nim powiedzmy ciąg 350 bajtów. W tym przypadku na dysku zapisane zostanie zapewne 4096 bajtów (domyślny rozmiar jednostki alokacji)
Jeżeli jest to plik .doc, który wewnętrznie ma strukturę binarną podobną do systemu plików, to jest szansa że Word zapisze dane tylko w tym miejscu które się zmieniło.
Ale jeśli jest to plik .docx, który jest .zipem wewnątrz którego jest .xml i inne pliki (o czym można się przekonać zmieniając rozszerzenie z docx na zip), to najprawdopodobniej na dysk zostanie przewalony cały megabajt.
0
Jeżeli jest to plik .doc, który wewnętrznie ma strukturę binarną podobną do systemu plików, to jest szansa że Word zapisze dane tylko w tym miejscu które się zmieniło.
Jeśli chodzi o SSD to nie działają one tak jak HDD, gdzie można sobie indywidualnie przestawiać pojedyncze bity na talerzu. SSD działa mniej więcej jak płyta wielokrotnego zapisu, a w zasadzie to każde ok 256 KiB pamięci flash jest taką osobną wielokrotnie zapisywalną płytą. Każdy taki kawałek jest zapisywany sekwencyjnie, a potem, gdy dane się zdezaktualizują lub zostaną przeniesione, zostaje całościowo zresetowany.
Tak przynajmniej zrozumiałem z artykułów o SSD.
tak czy inaczej, format docx nie sprzyja nośnikom SSD, bo zmiana nawet jednej litery wymusza nadpisanie całego dokumentu, lub sporej jego części. - Azarien 2 minuty temu
A sprawdzałeś?
Poza tym DOCX to ZIP z wieloma plikami, a ZIP ma to do siebie, że pliki w archiwum są kompresowane oddzielnie, więc gdy zmienisz jeden plik to resztą może zająć się algorytm deduplikacji, o ile oczywiście dysk SSD takowy ma i jest on w stanie takie rzeczy obsłużyć.
0
Zanim zaczniecie się martwić o żywotność dysku SSD przy zapisywanie pliku Worda co minutę polecam sprawdzić w monitorze zasobów jak często system i inne aplikacje piszą po dysku systemowym (podpowiem - ciągle).
Używam dysku SSD od dwóch lat bez żadnej manii ograniczania zapisów i trzyma się bardzo dobrze.
1
Jeżeli się pomyśli że każdy bajt może być zapisany tylko przykładowo 1000 razy to faktycznie boli zapisanie każdego bajta na dysku
Ale jeśli się pomyśli o tym tak że 128 GB dysk może być zapisany 1000 razy w całości - czyli jeżeli będziemy kasować codziennie całą zawartość dysku i zapełniać go po brzegi od nowa to wytrzyma on 1000 dni czyli prawie 3 lata - to już mniej to boli
A firmware w elektronice dysku pilnuje żeby dane były zapisywane po kolei a nie w tym samym miejscu, nawet jeżeli z punktu widzenia systemu operacyjnego będziemy zapisywać dane w tej samej komórce.
Nowsze dyski mają coraz więcej mechanizmów zapobiegających fizycznym zapisom na dysku - na pewno nie jest tak jak ktoś wyżej napisał że jeśli jednostka alokacji to 4 kB to za każdym bajtem jest zapisywane 4 kB - co najwyżej jest tyle alokowane, ale to nie znaczy że się cokolwiek zmieni w 4096 komórek pamięci.
Trzeba jeszcze pamiętać że między aplikacją a twardym dyskiem jest kilka warstw buforowania kończąc na kilkumegabajtowym cache dysku - oznacza to tyle że zapisując w kółko ten sam plik prawdopodobnie w ogóle nic nie robimy z dyskiem twardym; ten zapisze dane fizycznie dopiero gdy będzie taka konieczność
Czyli w skrócie: nie ma się co srać o to
0
Trzeba jeszcze pamiętać że między aplikacją a twardym dyskiem jest kilka warstw buforowania kończąc na kilkumegabajtowym cache dysku - oznacza to tyle że zapisując w kółko ten sam plik prawdopodobnie w ogóle nic nie robimy z dyskiem twardym; ten zapisze dane fizycznie dopiero gdy będzie taka konieczność
Niet. Wiele operacji pociąga za sobą impicite flusha, np zamknięcie pliku zawsze pociąga za sobą zrzut wszystkich zbuforowanych danych (dla tego pliku) na fizyczny nośnik.
http://www.gnu.org/software/libc/manual/html_node/Flushing-Buffers.html
Można to jednak obejść włączając pewne 'dangerous setting': http://blogs.msdn.com/b/oldnewthing/archive/2013/04/16/10411267.aspx
1
A kto powiedział, że flush na poziomie libc oznacza fizyczny zapis na dysku? To tylko zrzucenie bufora w libc, a nie systemu operacyjnego czy samego dysku. Wywołany jest w niej zwykły write.
1
Wibowit napisał(a):
Niet. Wiele operacji pociąga za sobą impicite flusha, np zamknięcie pliku zawsze pociąga za sobą zrzut wszystkich zbuforowanych danych (dla tego pliku) na fizyczny nośnik.
http://www.gnu.org/software/libc/manual/html_node/Flushing-Buffers.html
w tym linku nic nie ma o fizycznym zapisie na dysk
zrobienie flusha czy zamknięcie pliku daje tylko informację dla systemu żeby zapisać te dane, co nie znaczy że zrobi to od razu
no chyba że się mylę ale wtedy poproszę o link na temat i wyjaśnienie tego że jeżeli skopiujemy plik na dysk, a następnie w niedługim czasie odetniemy na chama zasilanie to dlaczego tego pliku nie będzie na twardym dysku? (możesz sprawdzić)
0
OK, poczytałem o Windowsie i tam jest tak, że nie ma implicite flushy, no chyba, że wybierzemy algorytm cachowania który stwierdzi, że będzie robił. No i takie ustawienia cachowania w Windowsie są, zarówno dla pamięci wymiennych jak i dysków twardych.
0
W mom notebooku ssd ma 32GB. Pomyślałem, że mogę tam zainstalować to c czego korzystam najczęściej czyli Office i Visual Studio. Jak myślicie, wystarczy tyle miejsca?
0
vincent25 napisał(a):
W mom notebooku ssd ma 32GB. Pomyślałem, że mogę tam zainstalować to c czego korzystam najczęściej czyli Office i Visual Studio. Jak myślicie, wystarczy tyle miejsca?
Już nie wnikając w kwestie nadpisywania plików to miejsce zapisania samych programów nie ma nic wspólnego z omawianym problemem. Offica i VS instalujesz jednorazowo, więc nie powinny mieć wpływu na zużywanie się SSD.
Natomiast problem leży w plikach, które korzystają z tych programów (np. .doc).
Przy tak niewielkiej pojemności dysku to ja osobiście przeznaczyłbym go tylko na system operacyjny i programy typu właśnie Office i VS. Natomiast projekty w VS lub pliki .doc zapisywałbym już na HDD.
0
Są programy do sprawdzania żywotności dysków. Polecam trzymać co się da na SSD i monitorować sprawę wspomnianym programem.
Ja w robocie mam laptopa z SSD i bez HDD, czyli inaczej mówiąc - wszystko jest na SSD. Wielokrotnie w ciągu dnia przebudowuję dość sporawą Javową biznesową kobyłę - sama kompilacja to dobry kwadrans z SSD i Core i5, do tego dochodzą jeszcze testy - drugie tyle. Stan dysku po paru miesiącach to 100% żywotności wg SSDLife Free, aczkolwiek ja aż tak optymistyczny to nie jestem.
0
To ja tak jeszcze profilaktycznie zapytam jaki program do backup-ów byście polecali.
Chodzi rozumiem, że SSD to minimum kilka lat pracy, ale jakby coś się stało to chciałbym odzyskać wszystko to co było na dysku głównym ;-)
1
Ciekawy napisał(a):
To ja tak jeszcze profilaktycznie zapytam jaki program do backup-ów byście polecali.
Skrypt powłoki.
0
Zobacz na to: http://mattmahoney.net/dc/zpaq.html
Ma sporo bajerów, ale niestety brakuje w formacie archiwum możliwości umieszczenia danych naprawczych.
Do danych naprawczych możesz jednak użyć osobnego programu, np: http://multipar.eu/
0
Jak ktoś ma nowego Worda, to może tu zapodać testem.
Stworzyć jakiś dokument, zapisać jako .doc i .docx. Zmienić jakiś wyraz czy zdanie, zapisać ponownie i dać wynik z diffa (opisowy) ile i gdzie się pozmieniało.
Mój OpenOffice nie obsługuje .docx więc nie mam jak sprawdzić.
Ja w pececie mam HDD tylko zewnętrzne, na USB. Siedzą tam dane w stylu muzy, filmów czy gier (których w sumie nie używam). A tak 100% danych tego peceta tylko na SSD. Ze dwa lata już wszystko śmiga (Windows 7).
1
Ale w OO jest podobna sytuacja co w MSO - stary format był binarny, nowy jest oparty na XMLu, dokładnie tak jak w przypadku MS.
0
Panowie a czy na dyskach SSD można wykonywać kopie obrazów całego dysku tak jak robiło się to na HDD? Chodzi o to, czy jest możliwość np kiedy zauważymy, że żywotność dysku spadła poniżej 20-15% przygotować sobie backup całego systemu i następnie po wymianie dysku na nowy zanim instalować wszystko od nowa wgrać po prostu obraz dysku?
0
tak, można (dziwne pytanie)
0
Odnośnie buforowania w warstwie jądro, system plików - z tego co zauważyłam np. domyślnie przy EXT4 do 5sekund buforuje (opóźniona alokacja) i zapisuje dane na dysk.
Marooned napisał(a):
Mój OpenOffice nie obsługuje .docx więc nie mam jak sprawdzić.
Może LibreOffice?
0
DOCX to nawet obsługuje WordPad w Windows 7 (a może dopiero w 8?). Mniejsza o to.
Stworzony czysty dokument w Wordzie 2007, zapisany w DOCX. Zawiera tekst "Hello, world.". Skopiowany do pliku Hello - Copy.docx. W oryginalnym pliku usunięto ostatni znak, kropkę. Zapisano.
fc /b "Hello - Copy.docx" Hello.docx > test.txt
Zawartość pliku test.txt w załączniku. Wystarczy tylko, że powiem:
E:\Marcin\Temp>wc -l test.txt
6809 test.txt
Analogiczny test dla DOC:
E:\Marcin\Temp>fc /b "Hello - Copy.doc" Hello.doc > test2.txt
E:\Marcin\Temp>wc -l test2.txt
744 test2.txt