From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20120113113026.GA419@polynum.com> <20120114003032.1C08F1CC8F@mail.bitblocks.com> <201201140201.51504.dexen.devries@gmail.com> From: =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= Date: Sat, 14 Jan 2012 17:16:36 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] fossil pb: FOUND! Topicbox-Message-UUID: 5c1e9f88-ead7-11e9-9d60-3106f5b1d025 erik quanstrom wrote: > i think it would be fair to argue that source and executables are > negligeable users of storage. =C2=A0media files, which are already compre= ssed, > tend to dominate. What about virtual machine images? > the tradeoff for this compression is a large amount of memory, > fragmentation, and cpu usage. =C2=A0that is to say, storage latency. I have 24GB RAM. My primary laptops have 8GB RAM. I have all this RAM not because of dedup but because I do memory intensive tasks, like running virtual machines. I believe this is true for many users. I'm of a completely different opinion regarding fragmentation. On SSDs, it's a non issue. Historically, one of the hardest things to do right in a filesystem was minimizing fragmentation. Today you don't have to do it so there's less complexity to manage in the file system. Even if you still have rotating rust to store the bulk of the data, a small SSD cache in front of it renders fragmentation irrelevant. My CPU can SHA-1 hash orders of magnitude faster than it can read from disk, and that's using only generic instructions, plus, it's sitting idle anyway. > so i wonder if we're not spending all our resources trying to optimize > only a few percent of our storage needs. Dedup is certainly not a panacea, but it's certainly useful for many worklo= ads. --=20 Aram H=C4=83v=C4=83rneanu