Peter Stahlir wrote:Yes, surely. Your idea suggests that you want any file to be reconstructed on-the-fly whenever it's being requested. Isn't there the danger of killing performance, the CPU being the bottleneck? I imagine such a debian mirror has quite some traffic. I doubt so. There sure is lots of redundancy within each file and that's what compressed file systems are good for. But what you talk about is redundancy across (unversioned) files, and I don't feel there is a lot of it. Yes, I might have a few copies of the file COPYING on my disk, and maybe some of my sources share a few functions, but this won't save me tons of space. All my binaries, libraries, MP3s, videos, config files, etc don't really have any redundancy across file boundaries. And even if there is, finding that redundancy is an O(whatever-but-not-n) operation that would be rather slow. I definitely see gitfs (or similar ideas) as potentially being useful in some cases (maybe debian mirrors could be one), but not for my disk at home, which I generally would prefer to be faster than more compressed. jlh - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 24/37] dccp: Processing Confirm options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | Re: [GIT]: Networking |
| david | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
