linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: artem.bityutskiy@linux.intel.com, linux-mtd@lists.infradead.org
Subject: Re: UBIFS question: Power-cuts after ubifs_leb_unmap()
Date: Tue, 31 Jul 2018 23:28:50 +0200	[thread overview]
Message-ID: <4560343.Ej1RjlWijI@blindfold> (raw)
In-Reply-To: <086b1694-a182-5873-a4c2-c754d8bf3cda@intel.com>

Am Montag, 30. Juli 2018, 10:07:25 CEST schrieb Adrian Hunter:
> > With grouped nodes a power-cut is okay, the bigger problem is the number of xattrs.
> > We support up to 2^16. Do delete an inode via journal we need UBIFS_INO_NODE_SZ bytes
> > in the journal.
> > So, in worst case we need to write 2^16 times UBIFS_INO_NODE_SZ bytes to the journal.
> > I'm still looking into this option right now, just to be sure that this is really the
> > solution to the problem I see. Finding a stable reproducer is also not easy...
> > 
> > Another possibility is playing with ubifs_tnc_remove_ino(), upon unlink() it removes
> > all entries from the TNC and marks them as dirty.
> > The problem is that also all xattr inodes are marked as dirty.
> > If we manage to find a way that these get marked only as dirty when we are sure that
> > they are gone the GC will no longer unmap a "used" LEB.
> > But that all is very tricky.
> 
> What about: add the inode to be deleted to orphans, then delete the xattrs
> one at a time, then when they are all gone, delete the inode and remove it
> from orphans.

Hmm, deleting one at a time still means that UBIFS has to write up to 2^16 times
to the journal.
But I agree this approach is better than allocating space for 2^16 inodes at once
in the journal.
Using the orphan list we can make sure that deletion still is atomic.

Thanks,
//richard

      reply	other threads:[~2018-07-31 21:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 10:11 UBIFS question: Power-cuts after ubifs_leb_unmap() Richard Weinberger
2018-07-09 12:21 ` Adrian Hunter
2018-07-09 13:11   ` Richard Weinberger
2018-07-10  6:58     ` Adrian Hunter
2018-07-24  8:01 ` Artem Bityutskiy
2018-07-25 22:29   ` Richard Weinberger
2018-07-30  6:55     ` Adrian Hunter
2018-07-30  7:28       ` Richard Weinberger
2018-07-30  8:07         ` Adrian Hunter
2018-07-31 21:28           ` Richard Weinberger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4560343.Ej1RjlWijI@blindfold \
    --to=richard@nod.at \
    --cc=adrian.hunter@intel.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).