Użytkownik "Andrzej P. Wozniak" <uszer@poczta.onet.pl.invalid> napisał w
wiadomości news:53722716$0$2155$65785112@news.neostrada.pl...
Mam OE, gdzie jest gigant danych (grubo ponad 100GB).
Czyli grubo za dużo.
Bo ponieważ??
* Bo się nie da tego przeszukać w całości. Im więcej małych wiadomości do
przeszukania, tym szybciej natrafia się na ograniczenia w stylu
niemożności
podejrzenia wyszukanej wiadomości czy jakiejkolwiek operacji na niej
(oflagowania, oznaczenia jako ignorowanej itd.)
Spoko, ja sobie poradzę z tym, czego potrzebuję. Zasadniczo, wiadomości będą
przerobione na pliki, OE ma ten mechanizm, że można, niestety, tylko 65535,
czy 6, plików za jednym przeniesieniem, jak dam więcej, to nie zrobi ani
jednego.
To oznacza, że np. widzi wolne miejsce na dysku tylko w granicach 4 GiB.
Im więcej dużych folderów, tym większe prawdopodobieństwo, że w którymś
momencie reszta z dzielenia wielkości wolnego miejsca przez 2^32 będzie
mniejsza niż wielkość folderu, który akurat trzeba skompaktować. Wyobraź
sobie, że masz wolnego miejsca 200 GiB i 1 MiB, ale OE widzi tylko 1 MiB,
więc krzyczy, że brak miejsca na skompaktowanie folderu o wielkości 2 MiB.
Zrobię to tak, ze kompaktowanie da sobie radę i z tymi 100 giga, czy więcej,
nie waląc tego w gigantyczną całość, tylko tę stówe rozdzielę na rzeszę
mniejszych plików, a one już raczej nie powinny "popękać".
* Bo obsługa wielu serwerów grup dyskusyjnych oznacza przerośnięty plik
folders.dbx, o czym już pisałem. Inne szczegóły niżej.
Jeśli będę uważać, co będzie z pewnością niewygodne, to mam nadzieję, że
zanim dojdzie do 2G, to złapię to i odpowiednio zadziałam. Cel nie ma zostać
w OE, tylko być przeniesiony do pojedynczych plików.
Gdybym wiedział, że będziesz znowu marudził, to bym się w ogóle nie
odzywał.
Ależ przecież nikt cię do tego nie zobowiązuje!
Ale piszę na grupę, a nie prywatnie, więc może inni skorzystają, choćby
plagiatorzy.
Oby.
Pominąłeś istotne dane, na które zwróciłem uwagę powyżej:
* Nie napisałeś, czy są to foldery lokalne, czy synchronizowane.
Korzystając
Synchronizowane są foldery grup dyskusyjnych, z których potem kopiowane są
tychże zawartości, do folderów lokalnych, a newsgrupy zostają skasowane. Z
folderów lokalnych zawartość wyleci do pojedynczych plików (zdaję sobie
sprawę z ich ilości, ale mam 2.5TB miejsca, więc będzie z dużym zapasem).
* Nie napisałeś, ile masz razem kont dla serwerów grup dyskusyjnych. Pełna
Jedno.
lista grup Usenetu ma ponad 100 tys. pozycji, co w pliku OE zajmuje ponad
To jest serwer-archiwum, więc grup jest niecały tysiąc. Zmieści się.
Folders.dbx kompaktowanie całości skończy się znanym komunikatem błędu
„Plik jest w użyciu…” – szczegóły patrz niżej.
Do 1.8GB (chyba nie próbowałem większych) kompaktowanie udawało się -
przejście w offline, restart OE i właściwe kompaktowanie.
Kompaktowanie czego się udawało - folderu z wiadomościami? To nie nowina
Plik folderów tyle miał. Metoda z netu - przejście w offline, restart i
właściwe kompaktowanie dawała radę, choć nie zaw2sze, przyznaję. Tylko OE
przedzierając się przez pozostałe pliki - z danymi, robił to kilka godzin...
żeby choć wstępnie kompaktował FOLDERS.DBX na początku, to już było by
bardzo dużo.
A dlaczego ignorujesz różnicę między folderem z wiadomościami a plikiem
Folders.dbx, skoro tylko o ten ostatni pytasz?
Nie ignoruję. Wiem, że w folders.dbx nie zawiera wiadomości. Ale z
pobieraniem nagłówków i tak rozrasta się, choć przecież te nagłówki to
raczej folder wiadomości powinny "rozdmuchiwać", a nie ten metaplik.
A tu ignorujesz różnice między plikami lokalnymi a synchronizowanymi
oraz problemy z wyszukiwaniem.
Bo w tym momencie, to nie mam za bardzo potrzeby ich rozróżniać.
Empirycznie to wciąż ignorujesz różnicę między folderem z wiadomościami a
plikiem Folders.dbx. Folders.dbx blokuje się tak jak napisałem, choć nie
mam
Tylko dlaczego, jak ściągam nagłówki (nie wiadomości, tylko same nagłówki)
dla jakiejś grupy, to folders.dbx tak mocno się rozrasta? Już jak wiadomości
lecą, to nie jest tak ostro.
pewności, czy wynika to z samego rozmiaru pliku, czy może z łącznej liczby
grup na listach. Stwierdzone kilkakrotnie i potwierdzone przy okazji
pisania
poprzedniej wiadomości.
Niecały tysiąc, więc powinien udźwignąć. Skoro 10 tysięcy dawał radę, jak
kilka lat temu intensywnie próbowałem... to 1/10 nie udźwignie?
Jak coś jest do wszystkiego, to jest do niczego ;-P
Tak, wiem, ale tak się śmiesznie złożyło, że właśnie akurat ma być do
niczego :)
Zresztą, skompaktowany FOLDERS.DBX miał coś ok. 280 kB. A moż 680... w
każdym razie, grubo poniżej 1M.
Niemożliwe. Sama lista grup z neostrady (bez krótkich opisów) ma powyżej
4 MiB. 280 KB to może być news-archive.icm.edu.pl plus lista folderów
lokalnych.
No wreszcie, trafiłeś :)
A tenże serwer niemalże wyklucza użycie pośredników do celów, jakie mi są
potrzebne.
Ćwiczę teraz przycinanie od końca tego pliku, by spróbować choć część
struktury przywrócić do życia. Po uruchomieniu OE jakby coś
przeindeksowywał, plik rośnie powoli,
Który plik tniesz, a który rośnie?
folders, z nadzieję, że choć część struktury zostanie w drzewku. Po
uruchomieniu OE, zachowuje się on, jakby coś ostro indeksował, trwa to
kilka(naście) minut i albo wywali, jak przy przerośniętym folders.dbx, albo
struktury drzewka nie będzie ani kawałka.
Przypominam, jak wygląda praca z plikami OE. Dane są zapisywane blokami,
przy zmianach bloki ze starą zawartością są oznaczane jako skasowane, zaś
Zdążyłem zauważyć - przeglądanie nieskompaktowanych plików ujawnia ich starą
zawartość.
poprawiona zawartość jest dopisywana na końcu pliku, choćby zmianą było
tylko skasowanie niektórych wcześniejszych wpisów. Stąd plik po skasowaniu
danych zajmuje _więcej_ miejsca, zaś przycinanie końca uszkadza ostatnio
dodawane bądź modyfikowane dane, a nie tylko śmieci, jakie się tam
znalazły
z przyłączonych do pliku klastrów na dysku.
Zgadza się i w pełni się z tym liczyłem. Niestety, drzewko zniknęło
całkowicie (liczyłem, że starsza część choćby w kawałku powróci), nie
pierwszy raz mi wszystko poleciało.
OE ma wbudowane timeouty, o czym znowu przypominam. Dzięki temu nie wisi
w nieskończoność, tylko się poddaje po ok. 4 minutach. Na starszych
komputerach do timeoutu może dojść np. przy otwieraniu folderu z bardzo
dużą liczbą wiadomości, jak control.cancel z news-archive.icm.edu.pl.
A to nie problem, raz wywali, drugi wywali, za trzecim złapie. Na to akurat
nie narzekam.
W związku z tematyką cross + FUT warning.
Nie krosowałem, ani FUT nie widzę.
Bo nie chce Ci się zobaczyć, co jest u mnie w nagłówku, a tam znowu taki
sam
cross+FUT.
Już widzę, ale mimo eot, nadal widzę zaległości do odpowiedzi, a skoro ktoś
napisał, czuję się zobowiązany odpowiedzieć.
--
Spamerów i "pytaczy" informuję, iż bardzo narażają się na to, że ich
adresy e-mail będą podawane harwesterom służącym do rozsyłania spamu.
|