# Re: Beyond inotify recursive watches

1 messages from 2013-04-05 to 2013-04-05. Participants: Ramkumar Ramachandra.
Thread: https://gitlist.dev/t/33398

## Ramkumar Ramachandra, 2013-04-05 16:56

Subject: Re: Beyond inotify recursive watches
Message-ID: <CALkWK0ngNM-zrybHOtFGzm5aVnkFMPn1DP0h=2aUf=7b9_sh8A@mail.gmail.com>
URL: https://gitlist.dev/e/CALkWK0ngNM-zrybHOtFGzm5aVnkFMPn1DP0h%3D2aUf%3D7b9_sh8A%40mail.gmail.com
In-Reply-To: <20130405155534.GC21852@quack.suse.cz>

```
Jan Kara wrote:
>   Hum, I have somewhat hard time to understand what do you mean by
> 'magically optimized syscalls'. What should happen in VFS to speedup your
> load?

In retrospect, I think this is a terrible hack to begin with.  Tuning
the filesystem specifically for git repositories is inelegant on so
many levels, I can't recall why I ever thought it would be a good
idea.  Like all software, Git has scaling issues with ultra-large
repositories.  Too many stat() calls is just one of the problems:
there will be too many objects to do any operation at reasonable
speed, and the overall UX would just suck.  Instead of growing to a
huge monolithic beast that spawns off worker threads for everything
and ultimately dying off, I've decided that git should take a
different direction: it should work with well with many small
easily-composable repositories.  I've started work on this already,
and it looks very promising.

Let the filesystem people do what they do best: optimizing for all
applications uniformly.

```