Felix Miata wrote:
It's a seriously good thing storage densities continue to rise, and unit cost continues downward, but they don't necessarily interplay nicely with smaller sizing paradigms WRT backup strategies, or size limitations of backup media.
??? You lost me on this one. W/a backup, you usually concatenate all of the files -- so it doesn't matter if the block size of the source is 512b or 4k, the only thing backed up is actual size of the data (or less if you still use compression). So the really, wouldn't matter if you went to a 1MB block size WRT backups, as the backups only store the original data -- not the 'slack'.
Linux went to a 4KB page for almost all filesystems over a decade ago.
That's where defaults went. Not everyone uses defaults. I have far more filesystems using 1k blocks than those using larger. I use larger only where A/V media and iso files go if on 512b/s disks, which I have far more of than 4k/s disks.
--- Today, but disks with minimum physical block size of 4k/block have been around for more than 5 years, and most vendors are shifting to 4k block sizes exclusively. How many of those 512b-native sector size disks were purchased in the last 5 years? Even SSD's aren't immune from this as they also find more efficiencies in shifting to 4k minimum r/w sizes. Now you can argue that it slows down I/O for those small files, since to read or write 1 byte, the disk has to read or write 4k. But tons of small files are a reason why MS switched to a format of program resources that are stored in 1 file in a library format. So instead of 1-icon / widget, you load the oxygen.so (or dll on win), and load the entire library at one time. Now it doesn't matter whether you use 512b or 4kb, since the entire set is in 1 file, it's still 1 read for an entire set of icons. Same thing with 'config' files. Unix is till using .rc/.config files, but MS switched to putting all config files for a system or a user in 1 place -- a registry hive. They didn't do a perfect job, but if you have the registry mounted as a file system as on 'cygwin' or as is done in /proc or /sys, you still have file-like access to small config+setting files that can be an interface to a system library or 1-or-more files. MS went to that format about 2 decades ago, and while it could be improved upon, it's still more efficient in terms of speed and storage than 100's or 1000's of tiny files scattered over a disk.
So, yes, space wasting!
Not if the storage was optimized to begin with by grouping -- with access as easy as access to a mountable file system (pointing to /cygwin's /proc/registry tree). Just saying -- that much of that space wasting was due to space-wasting design. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org