GWB posted on Fri, 31 Mar 2017 19:02:40 -0500 as excerpted: > It is confusing, and now that I look at it, more than a little funny. > Your use of xargs returns the size of the kernel module for each of the > filesystem types. I think I get it now: you are pointing to how large > the kernel module for btrfs is compared to other file system kernel > modules, 833 megs (piping find through xargs to sed). That does not > mean the btrfs kernel module can accommodate an upper limit of a command > line length that is 833 megs. It is just a very big loadable kernel > module.
Umm... 833 K, not M, I believe. (The unit is bytes not KiB.) Because if just one kernel module is nearing a gigabyte, then the kernel must be many gigabytes either monolithic or once assembled in memory, and it just ain't so. But FWIW megs was my first-glance impression too, until my brain said "No way! Doesn't work!" and I took a second look. The kernel may indeed no longer fit on a 1.44 MB floppy, but it's still got a ways to go before it's multiple GiB! =:^) While they're XZ- compressed, I'm still fitting several monolithic-build kernels including their appended initramfs, along with grub, its config and modules, and a few other misc things, in a quarter-GB dup-mode btrfs, meaning 128 MiB capacity, including the 16 MiB system chunk so 112 MiB for data and metadata. That simply wouldn't be possible if the kernel itself were multi-GB, even uncompressed. Even XZ isn't /that/ good! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
