Re: SMR drive test 3: full 8TB partition, mount problems, fsck error after delete

[Marc Lehmann <schmorp@schmorp.de>]

On Tue, Sep 22, 2015 at 04:08:50PM -0700, Jaegeuk Kim <jaegeuk@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
      --==---/ / _ \/ // /\ \/ /      schmorp@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