On Tue, Sep 22, 2015 at 04:08:50PM -0700, Jaegeuk Kim <jaeg...@kernel.org> wrote: > Could you check without -o1, since I merged a patch to calculate the best > overprovision at runtime in f2fs-tools.
I assume I have it, as git pull didn't give me any updates. > For example, if you set 1%, we need to reserve 100 sections to do cleaning at > the worse case. That's why you cannot see the reserved area as just 1% over > total space. Ok, I tried with -o1, -o5, and no -o switch at all: switch df -h "Used" -o1 126GiB -o5 384GiB "" 126GiB So indeed, the manpage (which says -o5 is the default) doesn't match the behaviour. With -s1 instead of -s128, I get: 75GiB 100 sections at -s128 would be 25G, so I wonder what the remaining 101GiB are (or the remaining 75GiB). Don't get me wrong, a "default" ext4 gives me a lot less initial space, but that's why I don't use ext4. XFS (which has a lot more on-disk data structures) gives me a 100GB more space, which is not something to be trifled with. If f2fs absolutely needs this space, it has to be, but at the moment, it feels excessive. I'm also ok with having to wait for gc when the disk is almost completely full. The issue I have at this point is that f2fs reserves a LOT of space, and long before the disk even near getting full, it basically stops working. That's the point where I would have to wait for the GC, but f2fs just seems to sit idle. > > F2FS-fs (dm-18): Failed to initialize F2FS segment manager > > (http://data.plan9.de/f2fs-mount-failure.txt) > > I think the below patch should resolve this issue. Sounds cool! > > After this, df showed 185GB in use, which is more like 3%, not 1% - again > > overprovisioning seems to be out of bounds. > > Actually, 185GB should include FS metadata as well as reserved or > overprovision > space. It would be good to check the on-disk layout by fsck.f2fs. That's a lot of metadata for an empty filesystem. > > [ASSERT] (get_current_sit_page: 803) ret >= 0 > > [Exit 255] > > Actually, this doesn't report f2fs inconsistency. > Instead, these two errors are from lseek64() and read() failures in > dev_read(): > lib/libf2fs_io.c. > > Maybe ENOMEM? Can you check the errno of this function? That's very strange, if the kernel fails, I would expect some dmesg output, but the fs was mountable before and after. Unfortunately, I already went onwards with the next test. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
