Soit, mais dans mon exemple il s’agit bien d’un fichier « sans trou », que j’ai volontairement pas « hard linké ».
D'accord, mais la problématique est la même : tu n'as pas un 'filesystem full' tout de suite à la copie du fichier. Mais plus tard, à l'utilisation. Et oui ça pose problème.
Je ne connais pas de solution pour ça à part avoir de la place disque disponible. Mais est-ce un réel problème si d'un autre coté et statistiquement tu gagnes de la place de stockage ?
Tu peux avoir ce genre de gag avec des snapshots aussi, si tu modifies un fichier, il faut stocker les données d'origines dans le snapshot et les données écrites dans le fichier. Si tu n'as pas la place pour le faire ça ne marche pas, et la dessus df ne t'aidera pas plus.
Perso ça me choque pas plus que ça. J'ai toujours pensé que l'espace disque dispo est une approximation. D'ailleurs, qui n'est pas tombé comme un con en manque d'inode alors qu'il y a plein de place sur le disque ?
[^] # Re: Ça à l’air bien...
Posté par Patrick Lamaizière (site web personnel) . En réponse au journal Enlarge your ZFS pool. Évalué à 3.
D'accord, mais la problématique est la même : tu n'as pas un 'filesystem full' tout de suite à la copie du fichier. Mais plus tard, à l'utilisation. Et oui ça pose problème.
Je ne connais pas de solution pour ça à part avoir de la place disque disponible. Mais est-ce un réel problème si d'un autre coté et statistiquement tu gagnes de la place de stockage ?
Tu peux avoir ce genre de gag avec des snapshots aussi, si tu modifies un fichier, il faut stocker les données d'origines dans le snapshot et les données écrites dans le fichier. Si tu n'as pas la place pour le faire ça ne marche pas, et la dessus df ne t'aidera pas plus.
Perso ça me choque pas plus que ça. J'ai toujours pensé que l'espace disque dispo est une approximation. D'ailleurs, qui n'est pas tombé comme un con en manque d'inode alors qu'il y a plein de place sur le disque ?
les pixels au peuple !