[elektro] NTFS korlátai kérdés ( klaszterméret partícióméret szemszögéből )
Xorn
toth.endre at gmail.com
Sun Nov 5 12:15:24 CET 2017
Nézd a másik végéről. Vodafone, számlázási rendszer, minden hívásrekord 1
file, kb. 100-120 byte adat. 90 napos loghoz kell közel 8 millió könyvtár
(90 nap, 24 óra, 60 perc, 60 másodperc, azon belül a file-ok). És van 8
felé szolgáltatás, azaz nagyjából 60 millió könyvtár (!), amiben a file-ok
vannak.
Best regards,
Andy
On 5 Nov 2017 12:10, "Karoly Kovacs" <koka55 at gmx.at> wrote:
> Értelek, de belegondoltál valaha is, mekkora kib..ott nagy szám a 4 millió?
> A pénzek értéktelenedésével mindennapos fogalommá vált a millió (sőt a
> milliárd), de ha csak egyszer is belegondolsz, mennyi mondjuk 1 millió, meg
> fogsz ijedni. Egymillió lépés az kb. 700km. Mennyi idő alatt tudod
> megtenni? Egymillióig szóban elszámolni (saccra) másfél hétig tart (ha
> éjjel-nappal számolsz). Ha egymillió ceruzát egymás mellé fektetsz, kb. 7
> kilométernyi ceruzád lesz. És így tovább.
>
> Károly
>
> Cser Tamas wrote:
>
>> Xorn <toth.endre at gmail.com> írta, 2017. 11. 05.:
>>
>>> Anno egy digitális telefonközpont havi számlázását intéző C program 3300
>>> sor volt kommentekkel, mindennel együtt.
>>>
>>> Best regards,
>>> Andy
>>>
>>> On 5 Nov 2017 10:23, "Karoly Kovacs" <koka55 at gmx.at> wrote:
>>>
>>> Tamás!
>>>>
>>>
>> Ti mindannyian csak és kizárólagosan programolás szemszögéből látjátok
>> a világot, én meg programolás előtt akár apostolok könyvei, számozott
>> fejezetek, számozott versek, vagy csavarok nem ömlesztve, hanem
>> M8x15, M8x22, stb sok-sok fiókokra szétosztva,
>> törvények, rendeletek paragrafusok sok-sok fiókokra szétosztva
>>
>> neked úgy volt jobb, nekem meg így volt jobb
>>
>> Negyvenegynéhány éve űzöm az ipart (programolás), de bármiben lefogadom,
>>>> hogy egész életemben nem hogy 4 millió, de 100 ezer darab "képernyőnyi"
>>>> (ahogy Te mondtad) programmodult sem írtam. Tuti, hogy nem.
>>>> Egyebekben _nagyjából_ igazad van, azaz célszerű kisebb, átlátható
>>>> modulokból összerakni a programot. Amiben nincs igazad, hogy ezen
>>>> modulok
>>>> mérete nem Tőled/tőlem függ, hanem a logikailag együvé tartozó adat,
>>>> ill.
>>>> funkció mennyiségtől. Azaz nem jó a programot önkényesen "képernyő
>>>> méretű"
>>>> modulokra szabdalni, hanem úgy, ahogy a program logikája megkívánja.
>>>> Lehet,
>>>> hogy az egyik modul 10 soros, de az is lehet, hogy párszáz soros.
>>>> Ez a felvázolt gondolkodásmód tképpen az objektumorientált programozás
>>>> erősen pongyola megfogalmazásban. Hangsúlyozom a pongyola
>>>> megfogalmazást,
>>>> mielőtt a szakmabeliek fejbe vágnak érte. :)
>>>>
>>>> Károly
>>>>
>>>> Cser Tamas wrote:
>>>>
>>>> Kaczmarek Edvárd <edk-elektro at babakezek.hu> írta, 2017. 11. 04.:
>>>>>
>>>>>
>>>>>> Tamás,
>>>>>>
>>>>>>>
>>>>>>>> Mi a fene ez a 2GB partíció méret?!?!
>>>>>>>> Ez még nem FAT32, hanem FAT16 fájlrendszernél volt így.
>>>>>>>> A FAT32 már tud 2TB partíciót és 4GB fájlméret limitet.
>>>>>>>>
>>>>>>>> A FAT32 fájlrendszer méretkorlátai
>>>>>>>
>>>>>>> Fájlok maximális száma kötetenként 4 194 304 darab.
>>>>>>>
>>>>>>> nekem meg a MINIMÁLIS fájlméret a lényeg, ami 512bájt
>>>>>>>
>>>>>>> és így jön ki a 2GB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mi az istent tárolsz négymillió 512 byte alatti filében???
>>>>>>
>>>>>>
>>>>> mindenkinek meg van a maga gondolati világa,
>>>>>
>>>>> pl. nekem könnyebb, ha 10-20-40-max 50 sornál nem nagyobb blokkokban
>>>>> (azaz 1 képernyőméreten) is tudok szerveződni, és azt a főprogramban
>>>>> mindössze 1 sorban #include -olom
>>>>> és azokból az #include -okból majd a fordítóprogi rángatja össze
>>>>>
>>>>> ez nekem jobban bevált, mintha 300 - 3ezer - 10ezer soros állományban
>>>>> az elején és végén egy elütött if - endif -et kell keresgetnem
>>>>>
>>>>> van akinek úgy jobb, hogy az M3-as csavaranyákat összelapátolja az
>>>>> M4 M5 M6 M8 M10 csavaranyával aztán keresgéli, hogy van-e itthon
>>>>> 4db M5-ös anya és van aki kisebb fiókokba használat előtt
>>>>> szétválogatva
>>>>> tárolja, és hamarabb látja, hogy az M5-ös anyából már csak 3db van
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ed
>>>>>
>>>>>>
>>>>>> -----------------------------------------
>>>>>> elektro[-flame|-etc]
>>>>>>
>>>>>>
>>>>> -----------------------------------------
>>>>> elektro[-flame|-etc]
>>>>>
>>>>>
>>>>> -----------------------------------------
>>>> elektro[-flame|-etc]
>>>>
>>> -----------------------------------------
>>> elektro[-flame|-etc]
>>>
>>
>> -----------------------------------------
>> elektro[-flame|-etc]
>>
>>
> -----------------------------------------
> elektro[-flame|-etc]
More information about the Elektro
mailing list