Linux stat.st_atime hiba

Linux-haladó

Az atime a fájlhoz való utolsó hozzáférés idejét kéne, hogy mutassa.

Ha először megnézek például egy képet, és utána a fájl státuszát, akkor az atime a megnyitás idejét mutatja (helyesen).

Ha a gép bekapcsolva marad, és nincs nagyon terhelve (a fájl a bufferben marad), majd egy nap múlva megnézem újra azt a képet, utána az atime még mindig az előző napi megnyitás idejét mutatja (vagyis hibás).

  • 1138 megtekintés

( locsemege v | 2025. 12. 30., k – 11:25 )

Tehát azt sugallod, hogy az access time a file háttértáron való hozzáférését regisztrálja, azt nem, ha disk cache-ből kerül újra megnyitásra a file?

Logikus, hogy ez hiba, de égettem már meg magam azzal kapcsolatban, hogy jeleztem sort bugot, aztán lezárták a hibajegyet NOTABUG jelzéssel, meg azzal a válasszal, hogy olvassam el a specifikációt. Logikus lenne az, ahogyan én várnám el a működést, de nem az a specifikáció, és ahhoz képest jó a sort. Tehát lényegében a specifikációt lehetett rossznak tekinteni, nem az implementációt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem akarok dezinformálni, nem emlékszem pontosan. Szerintem a version sort-ot használtam (-V), s abban volt valami furcsa viselkedés. Mondjuk, mintha azt mondanám, hogy az 1.100 előrébb van a növekvő sorban, mint az 1.98. De ezt most írom fiktív példaként, egyáltalán nem biztos, hogy ez volt. Az a scriptem, amelyben használom, a mai napig is néha hibásan működik emiatt.

Arról van szó, hogy írtam egy shell scriptet egy rakás awk betéttel, amely képes egyes rpm csomagokat - config file-ban vagy parancssorban megadva - a Fedora build szerverről közvetlenül frissíteni, s így nem feltétlenül várom meg, amíg a csomag a hivatalos update repóban megjelenik. Ehhez ugye tudni kell, hogy a build szerveren melyik a legfrissebb csomag, valamint az frissebb-e, mint ami a számítógépre van telepítve jelenleg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( mitch0 | 2025. 12. 30., k – 14:06 )

Nincs noatime / relatime mount kapcsoló?

Az /etc/fstab fájlban a defaults van megadva.

A man mount-ban ezt találtam:

relatime 
          Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than or equal to the current modify or change time. (Similar to 
          noatime, but it doesn’t break mutt(1) or other applications that need to know if a file has been read since the last time it was modified.) 

          Since Linux 2.6.30, the kernel defaults to the behavior provided by this option (unless noatime was specified), and the strictatime option is required to obtain traditional semantics. In 
          addition, since Linux 2.6.30, the file’s last access time is always updated if it is more than 1 day old.

Ez lehet a magyarázat. (Bár szerintem nem logikus.)
 

Nagy Gábor   https://sign-el-soft.hu

ezért.

mert amikor a 'default'-ban még benne volt, mindeki átírta 'noatime'-ra - hogy gyorsabb legyen :)

 

hint: 

  • aki a default-ot használja, az fogadja el, hogy ez néha változik :)
  • ha meg konkrét filesystem flag-re épít saját megoldást, akkor konkrétan írja blele az fstab-ba a neki kellő paramétereket

Tehát, a default csak annak való, akinek ez mindegy, és jó úgy ahogy a 'nagyok' kitalálták ;)

szerintem :)

zrubi.hu

Törekszem rá. Sok idő megy el vele.

Az atime-ot arra akartam használni, hogy megnézhessük, mikor használtuk utoljára azt a sok elfekvő fájlt, aminek jó része feleslegesen foglalja csak a helyet. Például az emberek egy része nagyon sok fényképet készít, amit semmilyen módon nem rendez. Így aztán túl macerás lenne megtalálni köztük valami több éve készült képet, és ezért nem is nézi meg őket. Az atime segítségével arra akartam volna felhívni a figyelmet, hogy rendezni kéne a képeket.

A tapasztalatok alapján ez a munka mehet a kukába, mert az atime a Linuxon olyan mint a kutya vacsorája.

Nagy Gábor   https://sign-el-soft.hu

Ha így nézzük, akkor az is előfordulhat, hogy 1 éve rosszul volt beállítva az óra (dátum), s amiatt nem jó az atime. :)

Amúgy attól, hogy egy file olvasva volt, még lehet, hogy nem a felhasználó foglalkozott vele. Lehet, hogy antivirus, vagy valamilyen indexelő vagy backup vagy deduplikáló alkalmazás olvasta.

 

Mindezek ellenére, nem gondolom, hogy a progamod mehet a kukába, egyszerűen dokumentálni kell a rendszerkövetelményeit és a korlátait, s aztán a potenciális felhasználó majd eldönti, hogy jó-e neki vagy sem.

Nem az egész program megy a kukába, csak az atime-hoz kapcsolódó ötlet.

Meg akartam mutatni olyan ismerősöknek, akik nagyon sok képet csinálnak, hogy milyen keveset néztek meg azóta, hogy elkészült.

Azért nem nézik meg, mert nincs rendezve, és a sok kép között nehéz megtalálni amit keres.

(Azóta megnéztem, Windows és Android sem kezeli az atime-ot.)

Nagy Gábor   https://sign-el-soft.hu

Ha most elkezdesz használni valamit, és garantáltan öt évig ennek megfelelően fog működni a géped, akkor öt év múlva esetleg megmondhatod, hogy a figyelt fájlokat öt éve nem használtad.

De bármit is csinálsz azt nem mondhatod meg biztosan atime alapján, hogy mi történt az elmúlt öt évben.

Nagy Gábor   https://sign-el-soft.hu

Ez a magyarázat; amióta ez az agyrém a default, én mindenhol kézzel kiírom a strictatime-ot. SSD-nél nem okoz sem érzékelhető elhasználódást, sem lassulást számomra. Az atime (nem) frissülése viszont sokszor segít debugolásnál. Nem egy kifinomult eszköz, de meglepően sokszor hasznos.

FYI: az /etc/fstab sosem releváns, ha ilyet nyomozol. A ténylegesen aktív mount opciókat a /proc/mounts fájlból tudod kiolvasni, ez minden opciót tartalmaz, amit a kernel beleértetten rápakolt.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Szerintem nem buta kérdés, a válaszom mindenesetre az, hogy "tökmindegy". A múltkor kiszámoltam, hogy az új SSD-im az én tipikus írási gyakoriságommal, mennyiségemmel mennyi ideig bírják várhatóan, mire "elkopnak" (a gyártó által megadott max. írási kapacitás mellett): kb. 86 évig.

(Az én írási gyakoriságomat úgy számoltam ki, hogy a lecserélt, korábbi diszkeken megnéztem az addigi lifetime writes-t; ha jól emlékszem, a `tune2fs` programmal.)

Nem a strictatime-on fogok spórolni :)

megnéztem az addigi lifetime writes-t; ha jól emlékszem, a `tune2fs` programmal.)

hat akkor azert hibadzik a szamitasod. mivel MLC ssd-nel ha csak 1 bitet valtoztatsz is torol majd kiir egy teljes fizikai blokkot ujra, ami altalaban 32-256 MByte meretu.  smartctl-el (vagy windozon hdd sentinel) kell kiolvasni az ssd-bol az iras mennyiseget!

egyebkent nalam se pusztult meg el egy ssd sem, pedig van par amit nem kimeltem, foleg a berelt szerverekben levoket (ami sajnos sima desktop cucc, nem DC verzio)

de az egyetemen van olyan labor, ahol az uj ssd-s i7 munkaallomasokban fel ev utan sorra hullottak el az ssd-k...

Jó tipp, köszi. A smartctl-t is szoktam egyébként nézni (SSD-n legalábbis), csak elsősorban más sorát (Wear Leveling Count, úgy emlékszem). A régi össz-írást egyébként még nem is SSD-kről néztem le; az előző gépemben még "pörgő rozsda" egységek voltak :)

hat pont ezert nem lesz jo a szamolasod. egy atime 32bit adat valtozas, ami nem sok. viszont az ssd-n a teljes blokkot torolni kell, majd ujrairni. ami 2-4 Mbajt iras (nyilvan ezt a vezerlo teszi meg). vegigolvasol 1000 fajlt, mindegyiknek modosul az atime-ja, az 4k adatvaltozas, kozben az ssd cellakba beleraktal 2G irast.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( ng123 | 2026. 01. 04., v – 10:05 )

Eddig nem találkoztam a relatime, noatime, strictatime mount paraméterekkel, és azzal, hogy ezek közül a relatime az alapértelmezett.

Ezek a man mount-ban valóban le vannak írva.

De az mindenképpen hiba, hogy a man stat még csak utalást sem tartalmaz ezekre a mount paraméterekre, hanem ezt írja:

      st_atime 
             This is the time of the last access of file data.

 

Nagy Gábor   https://sign-el-soft.hu