> For the complete documentation index, see [llms.txt](https://hernandez-kevin.gitbook.io/pintos-filesys/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hernandez-kevin.gitbook.io/pintos-filesys/fase-4-file-system/inode.md).

# Inode

Unix likes this

## Un poco de explicación...

Para esta fase, es requerido que los archivos tengan la capacidad de crecer. Como una implementación base, el **File System** que tenemos es un modelo de ***Contiguos Allocation File System***. Como sabemos, un modelo de este tipo tiene la gran desventaja que no le permite a los archivos crecer cuando su contenido se extiende (lo mismo en caso contrario).

Entonces, es necesario ***botar*** la implementación actual y ***construir*** un nuevo modelo. Realmente eres libre de implementar cualquier otro modelo de File System, pero el que recomendamos es el ***Indexed File System***.

Si tienes duda o estás inseguro de cómo funciona un Indexed File System, es momento de tomar una pausa e ir a investigar sobre el tema.

Ahora bien, los archivos de PintOS no crecen más de 8MB, entonces, necesitaremos de 10 bloques directos, 1 bloque indirecto y 1 bloque doble indirecto.

{% hint style="info" %}
El uso de la matemática es muy fuerte en esta etapa. Asegúrate de estar en óptimas condiciones porque cualquier error en los números es fatal.\
Por último, debo hacerte el spoiler que estarás utilizando exhaustivamente las operaciones ***floor*** y ***ceiling*** (no están implementadas con esos nombres).
{% endhint %}

La unidad que estarás manejando son ***Sectores***. Un sector tiene como tamaño ***512 Bytes***. (Es un número ***muy importante*** para esta etapa).

Ahora bien, como reestructuraremos el File System, debemos de reimplementar las operaciones básicas:

* inode\_create()
* inode\_read\_at()
* inode\_write\_at()

Claro, conservaremos un par de variables pero prácticamente es borrón y cuenta nueva.

## inode\_disk vs inode

Ambos parecen ser lo mismo pero no lo son.

El ***inode\_disk*** es la estructura que usa para almacenar los archivos en disco (en este caso, un inode) mientras que el ***inode***, es la referencia al archivo.

## Indexed File System

Como se mencionó anteriormente, se hará un modelo muy similar al de un inode.

Nuestro nuevo inode es el siguiente:

```c
struct inode_disk {
		/*
			This is the actual header of the file. It stores everything about the file:
			- Indexes of direct blocks
			- Indexes of indirect blocks
			- Indexes of double indirect blocks
			- Size of file
		*/

		// Reminder: block_sector_t is a uint32!!
		block_sector_t direct_blocks[10];
		block_sector_t indirect_block;
		block_sector_t double_indirect_block;


		unsigned magic;                     /* Magic number. */
		off_t length;                       /* File size in bytes. */

		/*
			El inode debe cumplir la caracteristica que su tamaño debe ser
			exactamente 512 Bytes.
			Debes calcular cuantos bytes restantes del sector quedan sin uso.
		*/
		uint32_t unused[XXXXXX]; 
	};
```

Y pues... déjame comentarte que ya no quiero ser misericordioso. Para las últimas funciones que quedan te dejaré el reto de cómo empezar :D

## FAQ

* ¿Qué pasa si implemento otro tipo de File System?

  Salta toda sección de ***inode***, amigo mío.
* ¿Habrán funciones extras que tengo que hacer y modificar?

  ¡Absolutamente!