momtoronomyotypaldollyochagi...

1. olać backup .) , Deus ex machine 31/07/13 13:54
   dane w tej macierzy będą miały kopię. Zależy mi, żeby dało się na tych danych szybciej operować niż na kopii.
   Teraz przy jeszcze nie kompletnych danych kopiowanie (zwykle cp pod linuxem) 500GB z dysku na dysk trwa kilka godzin. Nie wiem czy to norma, czy coś źle ustawione. Niestety SATA II.

   "Uti non Abuti"

   1. zakladajac , elliot_pl 31/07/13 14:01
      staly transfer na poziomie 60MB/s to by zajelo nieco ponad 2 godziny. Ale z tego co piszesz masz tam miliony malych plikow, a to powoduje ze transfer idzie w dol, wiec te srednie 60MB/s moze i tak byc zbyt optymistyczne. Ciesz sie ze nie zgrywasz tego na USB, bo bys liczyl w dniach :D
      
      Chcialem ci zaproponowac jakas macierz dedykowana do tego, ale piszesz ze nawet SSD nie wchodzi w gre ze wzgledu na koszty. Dlatego tez sie wstrzymam :)
      
      Jesli budzet cie cisnie i dane mozna stracic, to raid0 powinien ci nieco pomoc.

      momtoronomyotypaldollyochagi...

   2. Kopiowanie z buforowaniem , Mute 31/07/13 14:15
      i juz.

   3. a jaki masz tam system plików , Master/Pentium 31/07/13 15:23
      oraz ile RAM?

      Nie ma tego złego , co by się w gorsze
      obrócić nie mogło - jak nie wierzysz
      włącz komputer :-)

      1. tam gdzie? , Deus ex machine 31/07/13 15:26
         aktualnie 16GB i ext4. A do macierzy mogę coś nowego sklecić.

         "Uti non Abuti"

         1. spróbuj reiserfs , Master/Pentium 31/07/13 17:08
            powinno pomóc.

            Nie ma tego złego , co by się w gorsze
            obrócić nie mogło - jak nie wierzysz
            włącz komputer :-)

I fix shit
http://raszpl.blogspot.com/

1. mistrzuniu , Deus ex machine 31/07/13 18:52
   żeby przeparsować, to najpierw muszę je mieć gdzie trzymać. I z tych kilku TB, zostanie pewnie okoł 100GB danych, przed raportowych. Na tym to już pójdzie szybciej. To już opracuje na SSD, które mam.

   "Uti non Abuti"

   1. no ale to parsowanie , RusH 31/07/13 21:55
      mozesz odpalic raz bez zadnego raida, niech nawet ora 2 dni
      wiec w czym problem?

      I fix shit
      http://raszpl.blogspot.com/

      1. jeśli przeparsować , Deus ex machine 1/08/13 00:24
         mam tyko raz to nawet bym nie zapisywał źródła, tylko robił to w locie. Sęk w tym że parsowanie musi iść kilka razy i tutaj potrzebuje tych źródeł. Jedno parsowanie gotowych źródeł zajmie dzień lub dwa - uwielbiam BigData .) A jak się zdupi, to poprawić parsery i od nowa .)

         "Uti non Abuti"

         1. Nie no facet. Jak wiecej niż raz to pchaj w baze. , ptoki 1/08/13 07:31
            Byle nie w bloby. Zwykle varchary.
            Nawet mysql.
            I bedzie dobrze. Zapisz w baze zgodnie z kolejnością w jakiej będziesz parsować i bedzie sporo lepiej.
            
            No i jak daver ci napisał - xfs jest na tych wykresach najsłabszy.
            1. nie mam na tyle zasobów , Deus ex machine 1/08/13 12:53
               sprzętowych, żeby tyle w bazę wpakować .)
               Od 6h taruję (bez kompresji) wstępne parsowanie chyba 1/5 całości danych. Jeszcze nie skończył, a już 6GB tar się ukulał i rośnie.

               "Uti non Abuti"

1. i sprobuj dobrać odpowiedni FS: , ptoki 31/07/13 23:05
   http://monolight.cc/...l-file-performance-on-hdds/
   
   Jesli chcesz dłubac jakiś raid to możesz sprobować ale to duzo nie da. Duzo ramu warto dac.
   1. na ramie , Deus ex machine 1/08/13 00:29
      już noSQL siedzi i chrupie swoje .)
      Do tych pomiarów mają fajną maszynkę, ale widzę że xfs rządzi. Popróbuję .)

      "Uti non Abuti"

      1. he? , daver 1/08/13 05:23
         Jestes pewien, ze dobrze czytasz te wykresy? ;P XFS jest (a przynajmniej byl, bo ktos tam ostatnio sie nim zajal, a powyzszy test stary) daleki od rzadzenia w przypadku malych plikow. On byl (moze nadal jest) najlepszy do wielkich plikow.
         
         Jak podatne na kompresje sa te pliki? Zerknij na Btrfs z LZO.

         I use arch btw

         1. racja, źle odczytałem , Deus ex machine 1/08/13 12:55
            mało sypiam ostatnie kilkanaście dni. Czyli ten ext4 nie taki zły .)

            "Uti non Abuti"

            1. Z ciekawosci... , daver 1/08/13 20:46
               zrobilem maly (bo ograniczony zaledwie do kopiowania) tescik porownawczy.
               
               Linux 3.10.4, HDD ST3250410AS, 1 partycja na calej powierzchni, 1 katalog, 100 000 plikow tekstowych o wielkosci 2.8KiB kazdy. Kopiowanie calego katalogu w obrebie dysku.
               
               ext4 w defaulcie
               ===========
               real 12m8.523s
               user 0m0.843s
               sys 0m9.567s
               
               reiserfs 3.6 w defaulcie
               ===========
               real 14m51.297s
               user 0m0.680s
               sys 0m13.780s
               
               btrfs compress=lzo
               ===========
               real 1m42.881s
               user 0m0.317s
               sys 0m6.403s

               I use arch btw

               1. zbiłem się z kolejnym problemem , Deus ex machine 2/08/13 01:10
                  ilość inode na SSD osiągnęła 100% reiserfs, nie ma tego limitu ( nie wiem jak btrfs) - to kolejny plus.
                  Dzięki za testy, tylko nie wiem jak to w moim przypadku się sprawdzi, około 15mln małych plików. Jeśli jeszcze coś w locie ma to pakować i rozpakowywać, to chyba zamuli go nieco. Sprawdzam dziś reisera na żywca .)

                  "Uti non Abuti"

                  1. liczbe wezlow mozesz zmienic , daver 2/08/13 01:42
                     ale nie bez ponownego tworzenia FSa.
                     
                     Podczas kopiowania uzycie procka (2500k) nie przekraczalo 4% na btrfs z kompresja i 1% na ext4/raiserfs.
                     
                     
                     Przy okazji, zerknalem jak sprawa wyglada przy nieco wiekszych plikach.
                     
                     ext4 copy 50 000 x 50KiB (text)
                     real 8m53.869s
                     user 0m0.283s
                     sys 0m7.330s
                     
                     btrfs copy 50 000 x 50KiB (text)
                     real 1m20.913s
                     user 0m0.210s
                     sys 0m5.187s

                     I use arch btw