On Thu, Jun 11, 2009 at 04:44:30PM +0400, Michael Raskin wrote:
Hello.
I am continuing my tests of BtrFS under a practical workload. Recently
an incorrect poweroff (or maybe a small bug in BtrFS) caused a small
data loss. The actual damage was non-existent.
I used old
Chris Mason wrote:
2. I found a file which is listed in the directory, but stat on it
returns No such file or directory. Certainly, rm and unlink cannot
remove it. The partition has 14G in use. What can I do to provide a
useful piece of FS structure information? How can I remove the file
On Fri, Jun 12, 2009 at 03:08:58PM +0400, Michael Raskin wrote:
Chris Mason wrote:
2. I found a file which is listed in the directory, but stat on it
returns No such file or directory. Certainly, rm and unlink cannot
remove it. The partition has 14G in use. What can I do to provide a
Chris Mason wrote:
2. I found a file which is listed in the directory, but stat on it
returns No such file or directory. Certainly, rm and unlink cannot
remove it. The partition has 14G in use. What can I do to provide a
useful piece of FS structure information? How can I remove the file
Chris Mason wrote:
I'd say to send us the btrfsck output, it will help answer these
questions.
Oh, easily. Bad block number way beyond partition block count.
Btrfs deals in byte numbers not block numbers ;)
Interesting to know. Maybe just adding at in the message would reduce
confusion.
It
Chris Mason wrote:
That's all. Reading one of the damaged file actually returned
Input/output error - probably it tried to read beyond end-of-device. I
had to kill this file (practical testing means that to continue to use
my notebook normally I had to nuke the damaged file and get intact
On Thu, 11 Jun 2009, Chris Mason wrote:
Existing filesystems will be upgraded to the new format on the first
mount. All of your old data will still be there and still work
properly, but I strongly recommend a full backup before going to the new
code.
Auugh.
This is horrible. I just
On Fri, Jun 12, 2009 at 02:55:33PM -0700, Linus Torvalds wrote:
On Thu, 11 Jun 2009, Chris Mason wrote:
Existing filesystems will be upgraded to the new format on the first
mount. All of your old data will still be there and still work
properly, but I strongly recommend a full backup
On Fri, Jun 12, 2009 at 02:55:33PM -0700, Linus Torvalds wrote:
On Thu, 11 Jun 2009, Chris Mason wrote:
Existing filesystems will be upgraded to the new format on the first
mount. All of your old data will still be there and still work
properly, but I strongly recommend a full
An ioctl is needed to set compress flag (i.e. clear
BTRFS_INODE_NOCOMPRESS flag) on per file basis. This patch adds that.
Introduces a generic function to be used by subsequent patches.
Signed-off-by: Amit Gud g...@ksu.edu
Index: newformat2/fs/btrfs/ioctl.c
Add an ioctl to set 'nodatacow' flag on per file basis.
Signed-off-by: Amit Gud g...@ksu.edu
Index: newformat2/fs/btrfs/ioctl.h
===
--- newformat2.orig/fs/btrfs/ioctl.h
+++ newformat2/fs/btrfs/ioctl.h
@@ -67,5 +67,7 @@ struct
Add an ioctl to set 'nodatasum' flag on per file basis.
Signed-off-by: Amit Gud g...@ksu.edu
Index: newformat2/fs/btrfs/ioctl.c
===
--- newformat2.orig/fs/btrfs/ioctl.c
+++ newformat2/fs/btrfs/ioctl.c
@@ -1330,6 +1330,8 @@ long
Add the new ioctl to progs.
Signed-off-by: Amit Gud g...@ksu.edu
Index: btrfs-progs-unstable/btrfsctl.c
===
--- btrfs-progs-unstable.orig/btrfsctl.c
+++ btrfs-progs-unstable/btrfsctl.c
@@ -55,6 +55,7 @@ static void
Add the new ioctl to progs.
Signed-off-by: Amit Gud g...@ksu.edu
Index: btrfs-progs-unstable/ioctl.h
===
--- btrfs-progs-unstable.orig/ioctl.h
+++ btrfs-progs-unstable/ioctl.h
@@ -58,4 +58,6 @@ struct btrfs_ioctl_vol_args {
Add the new ioctl to progs.
Signed-off-by: Amit Gud g...@ksu.edu
Index: btrfs-progs-unstable/btrfsctl.c
===
--- btrfs-progs-unstable.orig/btrfsctl.c
+++ btrfs-progs-unstable/btrfsctl.c
@@ -57,6 +57,7 @@ static void
15 matches
Mail list logo
