Re: free space inode generation (0) did not match free space cache generation

[Duncan <1i5t5.duncan@cox.net>]

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