I see all those easy +1’s on other operating systems... I assume you all reproduced the problem on Windows???
Maybe also on actual hardware instead of a VM (with a VM harddisk emulation infrastructure with different powerfail handling)? I still see no prove that the symptoms are not in this category! But if you check the sqlite research: which other operating systems provide the same guarantees on power failure at the cost of a lot of performance? We are talking about flushing the NTFS journal to ensure everything for a single file is flished. Something which in multi user systems such as *nix really requires root permissions as it allows trashing performance for the entire system. Safety is a nice property, but you can’t get it via just these flushes. Usability is also important. And the rest of the system needs the same power safety security principles for these flushes to make sense. And then only in critical places, not after every small tempfile write. E.g. part of the design. Not as part of a low level function. If we are going this way we can stop all the fsfs v2 development and optimizations for our biggest market. If we go this way we are going to be several orders of magnitude slower anyway for fixing a few of our power loss issues. There is no use of shaving a few % in other places. Not every filesystem has the performance characteristics of ext2; a system without journal. This is moving back to the simplistic “Windows is slow” world we had around 1.5 before I joined the development. Looking at the number of corruptions reported over the past 4 years. How many users would be happier if the repository and/or working copy would be something like 400% slower to make it ‘somewhat less likely to corrupt on power failure’? Bert Sent from Windows Mail From: Justin Erenkrantz Sent: Saturday, May 18, 2013 6:00 AM To: Ivan Zhakov Cc: Bert Huijben; C. Michael Pilato; Philip Martin; Branko Čibej; Subversion Development On Fri, May 17, 2013 at 5:58 PM, Ivan Zhakov <i...@visualsvn.com> wrote: Yes, this will be good improvement anyway, but I think repository integrity should be first goal. +1! =P -- justin
