[Solar-tecnica] sobre discos y fs's

Mie Ago 10 15:46:15 CEST 2005

-----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
> Solar-tecnica en lists.ourproject.org
> http://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-tecnica
> 

- --
Ricardo A.Frydman
Consultor en Tecnología Open Source - Administrador de Sistemas
jabber: eureka en jabber.sk - 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-----