On 01/18/2018 11:27 AM, Christoph Hellwig wrote:
[adding Chris to the Cc list - this is about the awful ext3 data=ordered
behavior of syncing the whole file system data and metadata on each
fsync]
On Wed, Jan 17, 2018 at 03:57:53PM -0800, Linus Torvalds wrote:
On Wed, Jan 17, 2018 at 3:52 PM,
Hello,
There have been a few threads on making git more space efficient, and
eventually someone mentions tiny files and space fragmentation. Now that git
object names are decoupled from their compression, it's easier to consider a
a variety of compression algorithms. I whipped up a really
On Thursday 21 April 2005 11:41, Linus Torvalds wrote:
On Thu, 21 Apr 2005, Chris Mason wrote:
There have been a few threads on making git more space efficient, and
eventually someone mentions tiny files and space fragmentation. Now that
git object names are decoupled from
On Thursday 21 April 2005 15:28, Krzysztof Halasa wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Wrong. You most definitely _can_ lose: you end up having to optimize for
one particular filesystem blocking size, and you'll lose on any other
filesystem. And you'll lose on the special
On Wednesday 20 April 2005 02:43, Linus Torvalds wrote:
On Tue, 19 Apr 2005, Chris Mason wrote:
I'll finish off the patch once you ok the basics below. My current code
works like this:
Chris, before you do anything further, let me re-consider.
Assuming that the real cost of write-tree
On Wednesday 20 April 2005 11:40, Linus Torvalds wrote:
On Wed, 20 Apr 2005, Chris Mason wrote:
Thanks for looking at this. Your new tree is faster, it gets the commit
100 patches time down from 1m5s to 50s.
It really _shouldn't_ be faster. It still does the compression, and throws
6 matches
Mail list logo