On Tue, Jan 20, 2015 at 12:46 AM, Felix Miata <mrmazda@earthlink.net> wrote:
Claudio Freire composed on 2015-01-20 00:29 (UTC-0300):
Felix Miata wrote:
Every installation, and upgrade, of netcfg, though often as few as 5 bytes, is writing a 4096 byte hostname/HOSTNAME sector (or possibly more) to the media, though no change to it/them has been made.
During every zypper dup, something is writing /etc/fstab, yet, its content matches the backup.
Many files in /etc/sysconfig get written during updating, yet remain unchanged from their backups.
This wastefulness is not common to other distros I have familiarity with. Why is it happening in openSUSE?
Do you do zypper dup often enough to worry about this?
There's more than one issue here. Did you read https://features.opensuse.org/313803 ever? Maybe it is trivial write volume, but there's the principle involved of wastefulness that applies not just in writing at update time, but also backup/restore processes.
It's irrelevant. That doesn't reference write cycles, and the post was about write cycles. I addressed the post (write cycles), and not the fate itself. In fact, it's not even clear doing what the fate indicates would improve write cycle efficiency, it may even make it worse (say, if the update script merely left the new file in place, and updated the timestamps on the old files repeatedly causing more metadata flushes).
SSD media, which I assume you're worrying about, buffer and batch writes internally so unless some of those writes explicitly fsync, writing 5 bytes in 100 files or 5000 bytes at once shouldn't matter much.
I don't understand why you wrote this. I'm not at all concerned about efficiency here except as writing any sector at all is unnecessary. The file was not changed, so why the write?
Because batched writes get written in one flash sector (usually 2MB), and can contain more than one filesystem block. Writes, even random writes, on a block device backed by flash usually results in one single write cycle on one block. That's wear leveling at work.
Basically, count how many bytes (blocks?) in total are written to disk while updating, and unless you can significantly decrease that number, which files get touched matter less.
Again I don't get it. Writes are slower I/O than reads. In the case of file not changed, why any write at all?
If you write one block at all, the remaining 511 will usually be for free. So, why make a huge effort to avoid writing a few blocks if it's not going to report any benefit?
I'd worry more (way more) about logging.
A bigger can of worms to be sure, but little problems can batch up enough to break the camel's back.
It should all start from the lowest hanging fruit. It makes little sense to go for the highest first. For another example, new installations should use relatime by default. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org