"Kicsit ragodva meg a probleman es jobban atgondolva az otletedet (esetleg a lentebb emlitett range locking koncepciojaval) mukodhet a dolog."
Nem olvastam végig a threadet, de minek locking?
Nem csak három művelet kell neked:
- read
- delete
- add
a metaadatok meg SQL-ből jönnének? Mert ha igen, a locking az SQL-ben van. A fájl helyét egy auto incrementes szekvencia adja, vagy egy bitmap, vagy egy free/used lista adja, azaz garantáltan nem lesz ütközés, két processz nem fog egymás területére írni.
Vagy arra gondolsz, hogy a törlés okozhat race-t, mert kitörlöd az SQL-ből, kitörlöd a fájlból, de közben még lehet folyamatban olvasás?
Ha igen, rakhatsz garbage collect folyamatot rá, azaz a törlés az SQL-ből törlésre jelölést jelenti, amit aszinkron szabadít fel egy másik job, és mikor kitörölte az adatot, ténylegesen törli az SQL-t, így felszabadul az a slot.
"Viszont gyorsabban megkapom-e az x poziciotol/hoz seek-elve az aktualis 16 MB-os szeletemet, mintsem ha egyszeruen a filerendszertol kernem az xx/xx/xx/abcde file-t?"
Nézzük miből áll egyik és a másik.
Ha a fájlrendszerből kéred el, és tudod a fájl konkrét helyét (tudod):
- meg kell nyitnod, ez a fájlrendszerben egy rakás műveletet indít be (implementációfüggő, listákon gyalogol végig, vagy hashekben keres, csinál egy rakás dolgot)
- megkapod a FD-on a fájlt
- beolvasod
- lezárod
(persze mmapolhatod is, akkor a beolvasod elmarad, cserébe mmapokat/munmapot hívsz)
A másik megoldás (mmapolva a fájl):
- az mmapnak a téged érdeklő részét meghivatkozod, ha olyan az alkalmazásod, akár zero copy módon
Mérd ki, de nagyon csodálkoznék, ha az első lenne a gyorsabb. Többszörös mennyiségű kódot mozgatsz vele, amely adott esetben diszk IO-t is jelent (fájlrendszer metaadatok).
"Viszont meg egy lenyeges kerdes: ha a huge sparse file-bol torlok 123456 db 16 MB-os blokkot (random pozicioktol), akkor van-e mod arra (a teljes sparse file ujrageneralasan kivul), hogy a sparse file altal effektiven elfoglalt hely a 123456 * 16 MB-tal csokkenjen?"
Erre két megoldást tudok:
- a fentebb említett punch hole-t (google), ez néhol implementált, néhol nem
- ZFS-en ha a tömörítés be van kapcsolva, ha egy blokk csupa nullákból áll, sparse block lesz
Mivel FreeBSD-n legutóbb az első még nem volt, én az utóbbival operálok, azaz nálam a törlés annyi \0 kiírása (egy nagy write), amennyi adatot és ahol fel szeretnék szabadítani. Értelemszerűen ez elvileg pazarlóbb, mint a másik, de nekem eddig még nem volt bajom vele.