Devo preoccuparmi di "tail: tipo di file system non riconosciuto 0xbeefdead"?

Sto cercando di seguire un normale file di testo con tail -f -n 50 filename. Ottengo le informazioni dal file bene, tranne che ottengo sempre questo messaggio di errore:

tail: tipo di file system non riconosciuto 0xbeefdead

Succede su ogni file. Il 0xbeefdeadmi preoccupa - sembra un tag di hacker.

$ tail --version
tail (GNU coreutils) 8.4

tail

— kwknowles
fonte

Non dovrebbe essere 0xdeadbeefinvece? :P

— Devnull

Chiudi voto ritirato.

— slm

Probabilmente ovvio ma 0xDEADBEEF è spesso usato per indicare byte non inizializzati e cose del genere. BEEFDEAD è probabilmente una svolta intelligente su questo. en.wikipedia.org/wiki/Hexspeak (cerca deadbeef)

— user426724

@goldilocks: è una bella storia ma non c'è dubbio. Inoltre, correggi la chiave di blocco maiuscole.

— Ben Voigt,

@BenVoigt Caps lock a parte, ha fatto un punto valido. La domanda è perfettamente chiara: si sta solo chiedendo se la sua carne è normale.

— Navin,

Se ricevi questo avviso quando usi il filesystem StorNext e stai eseguendo coreutils8.21 o precedenti, non c'è molto di cui preoccuparsi; questo messaggio di avviso è previsto.

GNU tailha una conoscenza cablata di un certo numero di tipi di filesystem e avvisa quando incontra un tipo sconosciuto. Il supporto per il filesystem StorNext è stato aggiunto al tailin coreutilsnel mese di aprile del 2013, ed è stato rilasciato in coreutils8.22. Il commit è qui . Se non riesci a ottenere quella versione di coreutils, o desideri modificare e ricompilare tu stesso la fonte, ecco il diff da quel commit:

src/stat.c
@@ -399,6 +399,8 @@ enum
     return "selinux";
   case S_MAGIC_SMB: /* 0x517B remote */
     return "smb";
+  case S_MAGIC_SNFS: /* 0xBEEFDEAD remote */
+    return "snfs";
   case S_MAGIC_SOCKFS: /* 0x534F434B local */
     return "sockfs";
   case S_MAGIC_SQUASHFS: /* 0x73717368 local */

— Mark Plotnick
fonte

Perché un programma userspace come taildeve essere compatibile con un filesystem specifico? Immagino che ciò che intendo sia: non c'è astrazione del filesystem su cui possa fare affidamento?

@ illuminÉ, il motivo principale per determinare il tipo di filesystem è l'operazione "tail -f": il modo più efficace per capire se i nuovi dati sono stati scritti su un file varia da un filesystem all'altro.

— Mark

tailcon l' -fopzione usa inotifyse può. Ma inotifypuò solo monitorare i cambiamenti causati dall'attività svolta dal kernel del sistema locale. Quindi tailuserà inotifysolo se l'argomento file è su ciò che classifica come un filesystem "locale".

— Mark Plotnick,

E l'ultima informazione mancante è che il kernel non fornisce alcuna chiara indicazione che qualcosa non va quando si tenta di usare inotify su un filesystem che non lo supporta, quindi questo numero magico kludgefest è sostanzialmente l'unico modo sicuro per usarlo.