On Sat, Jul 11, 2015 at 11:43 AM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-11 18:44, Chris Murphy wrote:
journald can be configured to use however much persistent storage you want; it can also be configured to use only volatile storage.
Even when you tell it to use volatile storage, it uses a lot of disk space:
minas-tirith:~ # journalctl --disk-usage Journals take up 74.3M on disk. minas-tirith:~ # uptime 19:34pm up 4 days 21:29, 25 users, load average: 0.11, 0.21, 0.20 minas-tirith:~ # ls /var/log/jo* ls: cannot access /var/log/jo*: No such file or directory minas-tirith:~ #
A problem with journald is that you can not purge it of messages by classes, like erase all nntp entries. They take most of the megabytes above.
Btrfs uses substantially less metadata at mkfs time compared to XFS,
Really? I have to test that, because I know XFS takes very little.
I've done it with qcow2 and vdi files, just format the drives in a VM and see the size of the vm files change. But it might also be possible to do this with fallocated files and formatting them directly, mkfs.btrfs will format a file, I'm not sure about the others - they may need a loopback device setup first. Btrfs writes the least metadata of any of them. On a small file system it basically writes two superblocks that are less than 16KB each. A bit more gets written on first mount as the uuid tree and space cache are created but they still use less space than XFS, and a lot less space than ext4.
However, the big problem is snapshooting.
Well, then don't snapshot. The openSUSE 13.2 default snapper behavior is kinda ridiculous. It takes many snapshots often and isn't aggressive enough at deleting them. If that's how a USB stick installation behaves, then that's sub optimal but also isn't a Btrfs ding, it's a ding against the default behavior of snapper.
And on flash stickes, I would prefer f2fs, when it becomes available.
Btrfs is already flash optimized. The catch with f2fs is that defaults rarely are properly optimized for the specific flash you're using, and the information to properly optimize isn't revealed by the flash device. So you have to know what you've got in order to get optimized results with f2fs - there's a pile of mkfs and mount time options for this. If you get them right, f2fs performance will blow away anything, including Btrfs. But that's initial performance, I'm not sure how it stacks up as the fs ages, and gets fragmented. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org