{"thread":{"id":"33398","subject":"Re: Beyond inotify recursive watches","startedAt":"2013-04-05T16:56:15Z","lastAt":"2013-04-05T16:56:15Z","messageCount":1,"participants":["Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"213291","messageId":"CALkWK0ngNM-zrybHOtFGzm5aVnkFMPn1DP0h=2aUf=7b9_sh8A@mail.gmail.com","threadId":"33398","inReplyTo":"20130405155534.GC21852@quack.suse.cz","subject":"Re: Beyond inotify recursive watches","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-05T16:56:15Z","receivedAt":"2013-04-05T16:56:15Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jan Kara wrote:\n>   Hum, I have somewhat hard time to understand what do you mean by\n> 'magically optimized syscalls'. What should happen in VFS to speedup your\n> load?\n\nIn retrospect, I think this is a terrible hack to begin with.  Tuning\nthe filesystem specifically for git repositories is inelegant on so\nmany levels, I can't recall why I ever thought it would be a good\nidea.  Like all software, Git has scaling issues with ultra-large\nrepositories.  Too many stat() calls is just one of the problems:\nthere will be too many objects to do any operation at reasonable\nspeed, and the overall UX would just suck.  Instead of growing to a\nhuge monolithic beast that spawns off worker threads for everything\nand ultimately dying off, I've decided that git should take a\ndifferent direction: it should work with well with many small\neasily-composable repositories.  I've started work on this already,\nand it looks very promising.\n\nLet the filesystem people do what they do best: optimizing for all\napplications uniformly.\n"}]}