Linda Walsh said the following on 02/11/2013 05:54 PM:
Anton Aylward wrote:
> Or are you creating a new partition with a ReiserFS for > /var/spool/news *AND* converting /var itself to a ResiserFS? I am only converting complete /var to ReiserFS and keep the same size for /var. I doubt it very much. You'd have the same problem about inodes vs data that you had with ext4.
Give the above, why not switch to a file system that allows you change the percentage space given to inodes, 'after the fact'? I don't know which file systems support this besides 'xfs' (using xfs_growfs -m).
Seems like that might be worth some minor consideration.
Let me get this right. As with the extN file systems, you can grow XFS. But you still get the situation the OP met, the 'out of space' message even though 'df' says there is space .... and you scratch your head and then finally go 'Ahh!' and run 'df -i' and see that Iuse% is 100. The you "grow" -- change - the percentage of the FS given to inodes. Ah, but the man page says In order to grow a filesystem, it is necessary to provide added space for it to occupy. Can you alter the inode %age "in place"? The whole point of the B-Tree File systems such as ReiserFS and BtrFS is that there is no fixed pre-allocation of space into inodes and data. The nature of the b-tree means space is allocated dynamically. You can't run out of inodes because there was never fixed number of inodes in the first place. If you get the 'out of space' message it really is time to resize, and you can resize with ext[34], just not on live systems. And yes like the manual page for XFS_grow says, use LVM. Fragmentation? To be honest I take that with a grain of salt. Yes it may be relevant with the 'linear' file systems (not least of all the ones with bit-mapped allocation algorithms, think MS-DOS/FAT). But by definition Btree's are always going to optimal give the available space. I say 'optimal' and 'given available space' since the asynchronous release and demand for file space in a multi-user system will always tend to produce some fragmentation. That being said, on a virgin file system of any kind, laying down an installation AND FREEZING IT will mean you have no fragmentation. Its the 'churn' that causes fragmentation (unless you have a very screwed up allocator!) As to the 'oldest', well the ReiserFS was integrated into Linux before XFS was, and BTree file systems have a long history. Go google. And please don't try to tell me that the idea was based upon Microsoft's NTFS. IBM's JFS and the VERITAS File System both predate XFS. To be fair, there was a hefty burst of development in file systems for UNIX variants in the early 1990s. There are older file systems for UNIX/Linux. There's even the 'original' version 7 file system code hanging around somewhere. That was fun to try and optimise but I'm so glad its long past! If you really want to be picky, IBM was using B-Tree access systems under VSAM in the early 1970s. You may choose to say that VSAM isn't really a 'file system', but we can get into a pissing match as to whether or not IBM "datasets" were "files". -- Never forget: The road to Hell is paved with good intentions. So tread hard on good intentions. -- rjd4 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org