All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Rohner <andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
To: slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/4] nilfs-utils: cldconfig add an option to set minimal free blocks
Date: Mon, 20 Jan 2014 12:55:46 +0100	[thread overview]
Message-ID: <52DD0EC2.9060706@gmx.net> (raw)
In-Reply-To: <1390215908.3034.95.camel@slavad-ubuntu>

Hi Vyacheslav,

On 2014-01-20 12:05, Vyacheslav Dubeyko wrote:
> I suppose that it should be made by nilfs_cleanerd by itself but not an
> user.
> 
>>> What will we have in situation when an user selects not proper value of
>>> threshold?
>>
>> Well that's the users problem. You could also ask what will happen if
>> the user selects an improper min_clean_segments value ;)
>>
> 
> I don't think that it is good approach not to defend an user from
> mistaken decision.

I guess my point was, that NILFS2 isn't the user friendliest file system
on the planet anyway. Good documentation in the config file and sensible
default values would probably be the best solution.

We could of course set some default value and remove the option from the
config file, but I think it is a powerful option and the user might want
to tweak it to his or her needs.

>>> I worried about situation of skipping sibling segments from cleaning. Is
>>> NILFS2 driver really ready for this? Did you think about efficiency of
>>> free space allocation after such cleaning and about file system
>>> consistency? Are you sure that all will be good after such approach of
>>> cleaning? I simply want to be sure that you have analyzed this.
>>
>> I tested it extensively and I am quite sure, that there are no problems
>> with that on the driver side.
>>
> 
> I want to listen the approach at whole and arguments how it works for
> the NILFS2 at whole. Such words as "I tested it and it works" is
> dangerous. Did you check your file system by fsck? I suppose that you
> don't. So, we need some reasonable description of concept that it prove
> your vision.

Ok I am sorry about that. Let me address all of your points:

If you look at nilfs_sufile_alloc in sufile.c you will see, that the
allocation algorithm basically just remembers the last allocated segment
in sh_last_alloc and then from there sequentially scans the SUFILE for a
clean segment. Thereby it checks the flags of the nilfs_segment_usage
structure and skips it if it is not clean:

if (!nilfs_segment_usage_clean(su))
	continue;

So it is perfectly capable of skipping segments that are left over at
random places.

Could that reduce the performance of the allocation algorithm? Probably
yes, but I don't think it would be significant. Most of the SUFILE will
be in Cache anyway.

I don't see how the file system consistency could be affected by just
updating a timestamp in the SUFILE. The value of su_lastmod is never
used in the driver. It is only set at creation time and used by the GC
to sort the segment list.

Best regards,
Andreas Rohner
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-01-20 11:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-19 14:01 [PATCH 0/4] nilfs-utils: new feature to skip inefficient gc Andreas Rohner
     [not found] ` <cover.1390139797.git.andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
2014-01-19 14:01   ` [PATCH 1/4] nilfs-utils: cldconfig add an option to set minimal free blocks Andreas Rohner
     [not found]     ` <685e5c720189d1e451ed8a0d65581aa8c5a3f7f0.1390139797.git.andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
2014-01-20 10:14       ` Vyacheslav Dubeyko
2014-01-20 10:52         ` Andreas Rohner
     [not found]           ` <52DCFFEB.4070809-hi6Y0CQ0nG0@public.gmane.org>
2014-01-20 11:05             ` Vyacheslav Dubeyko
2014-01-20 11:13               ` Ryusuke Konishi
2014-01-20 11:55               ` Andreas Rohner [this message]
2014-01-19 14:01   ` [PATCH 2/4] nilfs-utils: cleanerd: add custom error value to enable fast retry Andreas Rohner
     [not found]     ` <a203a9d8105dc1b449e469158fb07fbffbf2da18.1390139797.git.andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
2014-01-20 10:46       ` Vyacheslav Dubeyko
2014-01-20 12:02         ` Andreas Rohner
2014-01-19 14:01   ` [PATCH 3/4] nilfs-utils: refactoring of nilfs_reclaim_segment to add minblocks param Andreas Rohner
2014-01-19 14:01   ` [PATCH 4/4] nilfs-utils: add support for and define some nilfs_argv flags Andreas Rohner
2014-01-19 14:02   ` [PATCH] nilfs2: depending on flags, update segment usage instead of cleaning Andreas Rohner
     [not found]     ` <1390140141-4432-1-git-send-email-andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>
2014-01-19 16:49       ` Ryusuke Konishi
     [not found]         ` <20140120.014916.57469358.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2014-01-19 17:17           ` Andreas Rohner
2014-01-21 14:17           ` Andreas Rohner
2014-01-20  9:43   ` [PATCH 0/4] nilfs-utils: new feature to skip inefficient gc Vyacheslav Dubeyko
2014-01-20 10:37     ` Andreas Rohner
     [not found]       ` <52DCFC61.7050608-hi6Y0CQ0nG0@public.gmane.org>
2014-01-20 10:54         ` Vyacheslav Dubeyko

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=52DD0EC2.9060706@gmx.net \
    --to=andreas.rohner-hi6y0cq0ng0@public.gmane.org \
    --cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.