From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: free space inode generation (0) did not match free space cache generation
Date: Tue, 25 Mar 2014 13:00:21 +0000 (UTC) [thread overview]
Message-ID: <pan$8258b$aea97c0c$211631c9$d306a8a9@cox.net> (raw)
In-Reply-To: 53309AF9.8090203@friedels.name
Hendrik Friedel posted on Mon, 24 Mar 2014 21:52:09 +0100 as excerpted:
>> But regardless of my experience with my own usage pattern, I suspect
>> that with reasonable monitoring, you'll eventually become familiar with
>> how fast the chunks are allocated and possibly with what sort of
>> actions beyond the obvious active moving stuff around on the filesystem
>> triggers those allocations, for your specific usage pattern, and can
>> then adapt as necessary.
>
> Yes, that's a workaround. But really, that makes one the slave to your
> filesystem. That's not really acceptable, is it?
Well, given the relative immaturity of btrfs as a filesystem at this
point in its lifetime, I think it's acceptable/tolerable. However, for a
filesystem feted[1] to ultimately replace the ext* series as an assumed
Linux default, I'd definitely argue that the current situation should be
changed such that btrfs can automatically manage its own de-allocation at
some point, yes, and that said "some point" really needs to come before
that point at which btrfs can be considered an appropriate replacement
for ext2/3/4 as the assumed default Linux filesystem of the day.
---
[1] feted: celebrated, honored. I had to look it up to be sure my
intuition on usage was correct, and indeed I had spelled it wrong
(fetted). Yay for online wictionary and google-define! =:^) Anyway, for
others who may not be familiar with the term, since I have the links open
ATM:
http://en.wiktionary.org/wiki/feted
https://www.google.com/search?q=define:feted
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-03-25 13:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <532DF38B.40409@friedels.name>
2014-03-22 21:16 ` free space inode generation (0) did not match free space cache generation Hendrik Friedel
2014-03-22 23:32 ` Duncan
2014-03-24 20:52 ` Hendrik Friedel
2014-03-25 13:00 ` Duncan [this message]
2014-03-25 20:03 ` Hendrik Friedel
2014-03-25 20:10 ` Hugo Mills
2014-03-25 21:28 ` Duncan
2014-03-25 21:50 ` Hugo Mills
2014-03-28 7:32 ` Hendrik Friedel
2014-03-22 18:13 Hendrik Friedel
2014-03-22 19:23 ` Duncan
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='pan$8258b$aea97c0c$211631c9$d306a8a9@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.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.