On Wed, 18 Feb 2015 15:07, Anton Aylward wrote:
On 02/18/2015 02:35 AM, auxsvr@gmail.com wrote:
This has been working here for the past 5 years.
That's fine, peter, but I really don't want to load R and all its dependencies just to run this the once to see what parameters I need to give to the creation of a ext4FS to move my photos there.
So far on this thread I'm disappointed that no-one really is trying to anwers the question i'm asking..
No, I don't want to use XFS. It solves the inode problem the same way that ReiserFS does.
No, I don't want to 'fergetaboutit', I've been bitten by inode/data imbalance/exhaustion. Its why I use ReiserFS and BtrFS. If I were so in lined I might have gone the XFS path instead of ReiserFS, si ce both are B-tree and both 'create' inodes dynamically and both are easily resizeable. But I went the ReiserFS route and that has proven stable and reliable.
Part of the reason I'm looking at ext4 is that size of the files under ~/Photography is pretty predictable. RAW files are *always* about 24M. The .xml files are *always* just a few k. The JPG files are *always* a few meg, always less than 10M usually only 2-3M,
Things in ~/Documents, ~/Downloads and ~/Music are much more variable.
So there's a lot of predictability to the files in ~/Photogrpahy. Both to the overall FS and to the actual layout of each file on the disk allocation. This sounds like something ext4 could take advantage of. What I'm surprised at is that none of the ext4 boosters have had that "yes, this is a good match for ext4". Perhaps it isn't or perhaps they are just rah-rah-rah fanbois who don't actually understand the technology :-O [snip]
A few thoughts before hand: - In the last five years, the ext4 guys learned about their failures, and adapted, too. Just not as loud as the BTRFS guys. - The deaulfts have gotten much better. - Still, for /home at least I'm going to overprovision the inodes. How do I calc my numbers for mkfs.ext4 / mke2fs? - to know about beforhand: 1. ca. number of files and dirs (see df -i /home) 2. ca. number of used 1k blocks (see df -k /home) 3. Partionsize. - Now I calc my median bytes per inode ratio: inodes density = used blocks / used inodes - Next I test what mke2fs would use as defaults. (If unmounted try on /home, with -n, else try loopback-file same size) "mke2fs -n /home" (In this example just a 8GB Partition gives:) [code] Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 524288 inodes, 2097152 blocks 104857 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2147483648 64 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 [/code] - Interesting for us here is the lines: [code] Block size=4096 ... 524288 inodes, 2097152 blocks [/code] - How many of our files would fall below "Block size" in percent? - How many directories would be oversized (default inode-size is 256) ("Block size"/256) - What bytes per inode ratio would be default? (here 2097152 blocks / 524288 inodes = 4 blocks per inode corrected to 1k blocks = 4block of 4k = 16kB per Inode) - For most cases a Block-size of 4k is OK, but the default bytes per inode ratio is to big for a /home partition, IMHO, I prefer a higher density for home, BS=2k BpI=4k. - Combined into the mke2fs command: "mke2fs -b 2048 -i 4096 [partition]" This would give me (for the same 8GB partion as before) [code] Filesystem label= OS type: Linux Block size=2048 (log=1) Fragment size=2048 (log=1) Stride=0 blocks, Stripe width=0 blocks 2097152 inodes, 4194304 blocks 209715 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=541065216 256 block groups 16384 blocks per group, 16384 fragments per group 8192 inodes per group Superblock backups stored on blocks: 16384, 49152, 81920, 114688, 147456, 409600, 442368, 802816, 1327104, 2048000, 3981312 [/code] - Inode ratio now: 4194304 blocks / 2097152 inodes = 2 blocks per inode with 2k blocks -> 4kB per inode For me as a programmer that is fine. 2 million inodes in a 8 GB space. Shorthand: Absolute bare mimimum: minimum_inodes = number of files + number of dirs / space_used * space_avail Two times that to be on the save side for minimum. Mixed environs (here big photo files + normal $HOME cruft) are not trivial, ca. 10000 inodes just for the normal $HOME cruft is a bare minimum to be save in long term. Does that help to answer your questions? - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org