-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerardo Diaz wrote:
Como andan gente? Un par de temas para que los charlemos... 1) Probaron SATA? Como les resulto? Lo recomendarian para un server en produccion?
serial ata, acá lo está usando un grupo de siderca, les preguntaré cuando los vea (a veces pasa hasta un mes) se agradecera el dato...
2) Que fs usan? porque? Yo, reiserfs en LVM, me resulto estable, rapido y confiable comparado con ext3. Nunca me anime (aun) a probar xfs....
uf, acá vengo --como buen cascote antediluviano que soy-- para decir que yo uso ext2 (acabo de fijarme con df -T por si alguno necesita saber como hacerlo) :)
y pregunto porque no sé, qué ventaja tienen esos filesystems que nombrás? o que desventaja tienen los mas viejos, aparte de > velocidad?
mmm, algunos articulos pa que lo entiendas, explicado mejor que yo: The journal Journalling filesystems solve this fsck problem by adding a new data structure, called a journal, to the mix. This journal is an on-disk structure. Before the filesystem driver makes any changes to the meta-data, it writes an entry to the journal that describes what it's about to do. Then, it goes ahead and modifies the meta-data. By doing so, a journalling filesystem maintains a log of recent meta-data modifications, and this comes in handy when it comes time to check the consistency of a filesystem that wasn't cleanly unmounted. Think of journalling filesystems this way -- in addition to storing data (your stuff) and meta-data (the data about the stuff), they also have a journal, which you could call meta-meta-data (the data about the data about the stuff). http://www-128.ibm.com/developerworks/linux/library/l-fs.html Journaling filesystems Waiting for a fsck to complete on a server system can tax your patience more than it should. Fortunately, a new breed of filesystem is coming to your Linux machine soon. Journaling filesystems maintain a special file called a log (or journal), the contents of which are not cached. Whenever the filesystem is updated, a record describing the transaction is added to the log. An idle thread processes these transactions, writes data to the filesystem, and flags each processed transaction as completed. If the machine crashes, the background process is run on reboot and simply finishes copying updates from the journal to the filesystem. Incomplete transactions in the journal file are discarded, so the filesystem's internal consistency is guaranteed. This cuts the complexity of a filesystem check by a couple of orders of magnitude. A full-blown consistency check is never necessary (in contrast to ext2fs and similar filesystems) and restoring a filesystem after a reboot is a matter of seconds at most. http://freshmeat.net/articles/view/212/ Tambien, http://www.linuxgazette.com/issue55/florido.html
_______________________________________________ Solar-tecnica mailing list [email protected] http://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
- -- Ricardo A.Frydman Consultor en Tecnología Open Source - Administrador de Sistemas jabber: [email protected] - http://www.eureka-linux.com.ar SIP # 1-747-667-9534 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFC+gUnkw12RhFuGy4RAh0XAJ9INI1WXFHrqpyLD8KyCIU1T8xXiQCeOb7V HM3DKAgJwNYX/mzL4TNhpQY= =TKNO -----END PGP SIGNATURE-----