On Tue, 2008-12-16 at 22:41 +0100, Kay Sievers wrote:
> On Tue, Dec 16, 2008 at 21:46, wrote:
> >> On Tue, Dec 16, 2008 at 20:37, Roland wrote:
> >> > i have come across a weird autocomplete issue i assume it is related to
> >> > btrfs.
> >> >
> >> > let`s have some dirs:
> >> >
> >> > /non-btrf
On Tue, Dec 16, 2008 at 21:46, wrote:
>> On Tue, Dec 16, 2008 at 20:37, Roland wrote:
>> > i have come across a weird autocomplete issue i assume it is related to
>> > btrfs.
>> >
>> > let`s have some dirs:
>> >
>> > /non-btrfs-mount
>> > ./linux
>> > ./testdir
>> >
>> > /brtfs-mount
>> >
A kernel 'BUG' was caught while I had compression enabled and was
performing a 'portage' update on my gentoo installation (which had
btrfs mounted for portage for some basic perf testing). It has
finished the rsync and was at the 55% mark of the portage cache
update... if that helps at all
> On Tue, Dec 16, 2008 at 20:37, Roland wrote:
> > i have come across a weird autocomplete issue i assume it is related to
> > btrfs.
> >
> > let`s have some dirs:
> >
> > /non-btrfs-mount
> > ./linux
> > ./testdir
> >
> > /brtfs-mount
> > ./linux
> > ./testdir
> >
> > now, if i do "cd t"
On Tue, Dec 16, 2008 at 20:37, Roland wrote:
> i have come across a weird autocomplete issue i assume it is related to
> btrfs.
>
> let`s have some dirs:
>
> /non-btrfs-mount
> ./linux
> ./testdir
>
> /brtfs-mount
> ./linux
> ./testdir
>
> now, if i do "cd t" in /non-btrfs-mount, "t" autoc
I agree that adding more options will add more complexity but it seems
the same amount of work in kernel space will have to be done
regarding lzo compression itself - it`s already there(since july 2007).
the in-kernel lzo is equivalent to minilzo.
(http://www.oberhumer.com/opensource/lzo/)
re
hi,
i have come across a weird autocomplete issue i assume it is related to
btrfs.
let`s have some dirs:
/non-btrfs-mount
./linux
./testdir
/brtfs-mount
./linux
./testdir
now, if i do "cd t" in /non-btrfs-mount, "t" autocompletes to "testdir"
same for linux - bash autocompletes
> I'd much rather have just one compression scheme per FS. If people need
> a specific compression scheme for a specific file, they can just
> compress it in userland.
yes, i also think one compression scheme per FS is absolutely sufficient.
> -Ursprüngliche Nachricht-
> Von: "Chris Maso
I agree that adding more options will add more complexity but it seems
the same amount of work in kernel space will have to be done. If we
support mutiple compression schemes somewhere the compression scheme
used will have to be stored so we know what to use in the future. If we
store it on the sup
Just realized that I never posted the link to the results from a few
weeks ago. These are from the November 20 git tree, just before the
move to the 2.6.28-rc based kernels. We have been having some issues
with the new kernel (unrelated to btrfs) that have kept us from getting
newer results.
On Tue, 2008-12-16 at 10:20 -0500, Lee Trager wrote:
> While I agree that the command you send should be possible it wasn't
> exactly what I was thinking. Currently I am working on a way for the
> user to individually set which files/directories they want compressed or
> not. What I was saying is t
While I agree that the command you send should be possible it wasn't
exactly what I was thinking. Currently I am working on a way for the
user to individually set which files/directories they want compressed or
not. What I was saying is that assuming you are in a mounted btrfs
directory you could d
12 matches
Mail list logo
