J. Bruce Fields wrote:
Old kernel versions may still get booted after brtfs has gotten a
reputation for stability. E.g. if I move my / to brtfs in 2.6.34, then
one day need to boot back to 2.6.30 to track down some regression, the
reminder that I'm moving back to some sort of brtfs dark-ages
Harvey Harrison wrote:
Oh yeah, and figure out what actually breaks on alpha such that they added
the following (arch/alpha/include/asm/compiler.h)
#ifdef __KERNEL__
/* Some idiots over in linux/compiler.h thought inline should imply
always_inline. This breaks stuff. We'll include this
Linus Torvalds wrote:
This is about storage allocation, not aliases. Storage allocation only
depends on lifetime.
Well, the thing is, code motion does extend life-times, and if you think
you can move stores across each other (even when you can see that they
alias statically) due to
Sunil Mushran wrote:
On 04/22/2011 04:50 AM, Eric Blake wrote:
That blog also mentioned the useful idea of adding FIND_HOLE and
FIND_DATA, not implemented in Solaris, but which could easily be
provided as additional lseek constants in Linux to locate the start of
the next chunk without
Eric Blake wrote:
On 04/24/2011 11:49 AM, Jamie Lokier wrote:
My problem with FIND_* is that we are messing with the well understood
semantics of lseek().
fcntl() looks a better fit for FIND_HOLE/DATA anyway.
With fcntl(), it would have to be something like:
off_t offset = start
Dan Magenheimer wrote:
Most important, cleancache is ephemeral. Pages which are copied into
cleancache have an indefinite lifetime which is completely unknowable
by the kernel and so may or may not still be in cleancache at any later time.
Thus, as its name implies, cleancache is not suitable
Edward Shishkin wrote:
If you decide to base your file system on some algorithms then please
use the original ones from proper academic papers. DO NOT modify the
algorithms in solitude: this is very fragile thing! All such
modifications must be reviewed by specialists in the theory of
Edward Shishkin wrote:
I have noticed that events in Btrfs develop by scenario not predicted
by the paper of academic Ohad Rodeh (in spite of the announce that
Btrfs is based on this paper). This is why I have started to grumble..
In btrfs, based on means started with the algorithm and ideas
Edward Shishkin wrote:
I'll try to help, but I am rather pessimistic here: working out
algorithms is something, which doesn't like timelines..
Nonsense. Working out algorithms is just work to an algorithm
designer, just like programming is work to a programmer. Sure, some
things are harder
