Hello,
I'd like to know if there has been any discussion about adding a new
feature to write (add) data at an offset, but without overwriting
existing data, or re-writing the existing data. Essentially, in-place
addition/removal of data to a file at a place other than the end of
the file.
Some
Hallo, Hugo,
Du meintest am 06.12.10:
But after copying about 300 MByte (part of a 1.5-GByte *.mpg) I
got no space left on device. Looks like balancing has stolen
about 300 GByte.
This sounds exactly like a problem I've had. What output do you
get from btrfs fi df /srv/MM?
I've just
On Mon, Dec 06, 2010 at 02:13:00PM +0100, Helmut Hullen wrote:
Hallo, Hugo,
Du meintest am 06.12.10:
But after copying about 300 MByte (part of a 1.5-GByte *.mpg) I
got no space left on device. Looks like balancing has stolen
about 300 GByte.
This sounds exactly like a problem
Hallo, Hugo,
Du meintest am 06.12.10:
Can you try that again with either the latest 2.6.37-rc, or with
the btrfs-unstable kernel? There's a bug in earlier versions that
breaks the reporting of RAID types, which is what I wanted to see
here.
Compiling 2.6.37-rc is no big problem, it only
Helmut -
On Mon, Dec 06, 2010 at 03:45:00PM +0100, Helmut Hullen wrote:
If/when I install 2.6.37-rc4: should I update btrfs (from the 20101117
version)?
I think that's the latest version.
How can I see that changing the kernel makes things better? It's more
and more difficult to
Excerpts from Nirbheek Chauhan's message of 2010-12-06 07:41:16 -0500:
Hello,
I'd like to know if there has been any discussion about adding a new
feature to write (add) data at an offset, but without overwriting
existing data, or re-writing the existing data. Essentially, in-place
Hallo, Hugo,
Du meintest am 06.12.10:
How can I see that changing the kernel makes things better? It's
more and more difficult to externalize (?) btrfs directories to
other disks ...
Updating the kernel won't fix the problem I'm thinking of (sorry).
It will, however, fix the bug that
On Mon, Dec 06, 2010 at 06:13:00PM +0100, Helmut Hullen wrote:
Hallo, Hugo,
Du meintest am 06.12.10:
How can I see that changing the kernel makes things better? It's
more and more difficult to externalize (?) btrfs directories to
other disks ...
Updating the kernel won't fix the
On Mon, Dec 6, 2010 at 9:35 PM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Nirbheek Chauhan's message of 2010-12-06 07:41:16 -0500:
[snip]
Some possible use-cases of such a feature would be:
(a) Databases (currently hack around this by allocating sparse files)
(b) Delta-patching
Excerpts from Nirbheek Chauhan's message of 2010-12-06 14:14:59 -0500:
On Mon, Dec 6, 2010 at 9:35 PM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Nirbheek Chauhan's message of 2010-12-06 07:41:16 -0500:
[snip]
Some possible use-cases of such a feature would be:
(a) Databases
On Mon, Dec 6, 2010 at 11:14 AM, Nirbheek Chauhan
nirbheek.chau...@gmail.com wrote:
As an aside, my primary motivation for this was that doing an
incremental backup of things like git bare repositories and databases
using btrfs subvolume snapshots is expensive w.r.t. disk space. Even
though
On Tue, Dec 7, 2010 at 1:05 AM, Freddie Cash fjwc...@gmail.com wrote:
On Mon, Dec 6, 2010 at 11:14 AM, Nirbheek Chauhan
nirbheek.chau...@gmail.com wrote:
As an aside, my primary motivation for this was that doing an
incremental backup of things like git bare repositories and databases
using
On Mon, Dec 6, 2010 at 12:30 PM, Nirbheek Chauhan
nirbheek.chau...@gmail.com wrote:
On Tue, Dec 7, 2010 at 1:05 AM, Freddie Cash fjwc...@gmail.com wrote:
On Mon, Dec 6, 2010 at 11:14 AM, Nirbheek Chauhan
nirbheek.chau...@gmail.com wrote:
As an aside, my primary motivation for this was that
Currently BTRFS has a problem where any subvol's will have the same inode
numbers as other files in the parent subvol. This can cause problems with
userspace apps that depend on inode numbers being unique across a volume. So in
order to solve this problem we need to do the following
1) Create
Hi!
I'm not sure whether this *should* be possible, but I think it *shouldn't*
crash:
I created a snapshot of the root directory within a subdirectory:
# mount /dev/sde2 /mnt
# cd /mnt
# mkdir save
# btrfs subvolume snapshot . save/snap1
# umount /mnt
Then I tried to mount the snapshot:
#
Michael Niederle wrote:
Hi!
I'm not sure whether this *should* be possible, but I think it *shouldn't*
crash:
I created a snapshot of the root directory within a subdirectory:
# mount /dev/sde2 /mnt
# cd /mnt
# mkdir save
# btrfs subvolume snapshot . save/snap1
# umount /mnt
Then
On Mon, Dec 6, 2010 at 7:40 PM, Li Zefan l...@cn.fujitsu.com wrote:
Michael Niederle wrote:
Hi!
I'm not sure whether this *should* be possible, but I think it *shouldn't*
crash:
It's currently not allowed to mount a subvolume which is not created in
the root directory of the default
We should drop dentry before deactivating the superblock, otherwise
we can hit this bug:
BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
...
Steps to reproduce the bug:
# mount /dev/loop1 /mnt
# mkdir save
# btrfs subvolume snapshot /mnt save/snap1
# umount
On 12/07/2010 04:48 AM, Josef Bacik wrote:
Currently BTRFS has a problem where any subvol's will have the same inode
numbers as other files in the parent subvol. This can cause problems with
userspace apps that depend on inode numbers being unique across a volume. So
in
order to solve this
C Anthony Risinger wrote:
On Mon, Dec 6, 2010 at 7:51 PM, Li Zefan l...@cn.fujitsu.com wrote:
We should drop dentry before deactivating the superblock, otherwise
we can hit this bug:
BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
...
Steps to reproduce the bug:
On Tue, Dec 7, 2010 at 2:12 AM, Freddie Cash fjwc...@gmail.com wrote:
On Mon, Dec 6, 2010 at 12:30 PM, Nirbheek Chauhan
nirbheek.chau...@gmail.com wrote:
But the behaviour of --inplace is not entirely to write out *only* the
blocks that have changed. From what I could make out, it does the
On Mon, Dec 6, 2010 at 7:05 PM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from Nirbheek Chauhan's message of 2010-12-06 07:41:16 -0500:
Hello,
I'd like to know if there has been any discussion about adding a new
feature to write (add) data at an offset, but without overwriting
This problem is found in meego testing:
http://bugs.meego.com/show_bug.cgi?id=6672
A file in btrfs is mmaped and the mmaped buffer is passed to pwrite to write to
the same page
of the same file. In btrfs_file_aio_write(), the pages is locked by
prepare_pages(). So when
btrfs_copy_from_user() is
23 matches
Mail list logo
