Re: [PATCH] enable core.fsyncObjectFiles by default

2018-01-21 Thread Chris Mason
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,

[PATCH] multi item packed files

2005-04-21 Thread Chris Mason
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

Re: [PATCH] multi item packed files

2005-04-21 Thread Chris Mason
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

Re: [PATCH] multi item packed files

2005-04-21 Thread Chris Mason
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

Re: [PATCH] write-tree performance problems

2005-04-20 Thread Chris Mason
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

Re: [PATCH] write-tree performance problems

2005-04-20 Thread Chris Mason
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