Re: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
Hi, > can anyone point me in the right direction? it looks like maybe > the SSD is failing to me (all the "slow link" and "capacity > changed to 0" stuff), but i really don't know. i knew there was > a reason they were selling these things cheap on Newegg!!! Yes, the read errors are coming all the way up from the hardware; I don't think this is a btrfs problem. There's not much btrfs could do to help, except (over time) grow to handle I/O errors without BUG()ing out. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: converting one-disk btrfs into RAID-1?
Hi, > Is it possible to turn a 1-disk (partition) btrfs filesystem into > RAID-1? Not yet, but I'm pretty sure it's on the roadmap. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Blog: "BTRFS is effectively stable"
Hi, > A friend of mine who builds storage systems designed for HPC use > has been keeping an eye on btrfs and has just done some testing > of it with 2.6.36 and seems to like what he sees in terms of > stability. > > http://scalability.org/?p=2711 This is nice to see, but we should be clearer about what stability means. This was just fio testing; it doesn't say anything about resilience to crashes, power offs, or the presence of corruption. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Update to Project_ideas wiki page
vels == We need ioctls to change between different raid levels. Some of these are quite easy -- e.g. for RAID0 to RAID1, we just halve the available bytes on the fs, then queue a rebalance. == DISCARD utilities == For SSDs with discard support, we could use a scrubber that goes through the fs and performs discard on anything that is unused. You could first use the balance operation to compact data to the front of the drive, then discard the rest. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ls & flush-btrfs-1 sit at 100% sys
Hi, > Is doesn't return, I check top and both ls and flush-btrfs-1 are > sitting at ~50% sys usage each. Does anything new appear in dmesg when the hang happens? Can you run alt-sysrq-t (show tasks) and send us the output for the ls process? - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tiny btrfs bug.....
Hi, > In stead, df reports the size of the partition to be about > 60GB. For each GB written to the partition, 2GB gets used. https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What to do about subvolumes?
Hi Josef, > 1) Scrap the 256 inode number thing. Instead we'll just put a > flag in the inode to say "Hey, I'm a subvolume" and then we can > do all of the appropriate magic that way. This unfortunately > will be an incompatible format change, but the sooner we get this > adressed the easier it will be in the long run. Obviously when I > say format change I mean via the incompat bits we have, so old > fs's won't be broken and such. Sorry if I've missed this elsewhere in the thread -- will we still have an efficient operation for enumerating subvolumes and snapshots, and how will that work? We're going to want tools like plymouth and grub to be able to list all snapshots without running a large scan. Thanks, - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG
Hi,
> Hi! I got a kernel BUG at
>
> fs/btrfs/disk-io.c:2311
>
> when testing the 2.6.37-rc5 kernel today.
It's good to mention which line this is, since the line numbers are
always changing. This is:
if (total_errors > max_errors) {
printk(KERN_ERR "btrfs: %d errors while writing supers\n",
total_errors);
BUG();
}
in write_all_supers(). Does dmesg say anything about the nature of
the errors above the BUG() line?
- Chris.
--
Chris Ball
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG
Hi Michael, >> in write_all_supers(). Does dmesg say anything about the nature >> of the errors above the BUG() line? > The message was output to the console of the crashed system - so > I'm sorry I cannot supply further informations. Ah, okay. You could consider installing kgdb/kdb -- it will let you drop to the kdb shell after the crash and run dmesg through a pager. Just: CONFIG_HAVE_ARCH_KGDB=y CONFIG_KGDB=y CONFIG_KGDB_SERIAL_CONSOLE=y CONFIG_KGDB_TESTS=y # CONFIG_KGDB_TESTS_ON_BOOT is not set CONFIG_KGDB_LOW_LEVEL_TRAP=y CONFIG_KGDB_KDB=y CONFIG_KDB_KEYBOARD=y and then boot with "kgdboc=kms,kbd" added. > But exactly the same crash happened again some minutes ago. (I'm > now back to my old kernel.) Not sure I understand. Do you mean that the same crash happens on your older kernel now, or that you've reverted to your older kernel because you had another -rc5 crash? If the crash happens on -rc5 but not the older kernel (what revision is the older kernel?), that's extremely interesting. Josef/Chris, any knowledge about hitting this BUG() on -rc5? - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG
Hi, > Currently I'm running with -rc7. If the system still runs > tomorrow morning I will do another test with -rc5 - this time on > the USB 3.0 port. This should show whether this is a hardware or > software problem. Thanks, sounds good. Yes, the location of the BUG() does suggest a hardware problem, assuming it's coded correctly. dmesg would tell us for sure, because the I/O error would be reported above the BUG() output. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -progs] Fix unused-but-set errors in gcc-4.6
gcc-4.6 (as shipped in Fedora) turns on -Wunused-but-set-variable by
default, which breaks the build when combined with -Wall, e.g.:
debug-tree.c: In function ‘print_extent_leaf’:
debug-tree.c:45:13: error: variable ‘last_len’ set but not used
[-Werror=unused-but-set-variable]
debug-tree.c:44:13: error: variable ‘last’ set but not used
[-Werror=unused-but-set-variable]
debug-tree.c:41:21: error: variable ‘item’ set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
This patch fixes the errors by removing the unused variables.
Signed-off-by: Chris Ball
---
This is a pretty big patch -- I'm happy to split it out per-file if
you'd prefer to review it that way. It's against the "next" branch.
It removes some #if 0 blocks completely; seemed easier to let that
code live on in Git history than to add #if 0 blocks around the
declarations of all the variables only used inside those blocks.
btrfs-map-logical.c |2 --
btrfsck.c | 15 ++-
ctree.c | 16
debug-tree.c| 43 +--
dir-item.c |2 +-
disk-io.c |4
extent-cache.c |6 ++
extent-tree.c | 30 --
extent_io.c |4
mkfs.c |2 --
print-tree.c|3 ---
utils.c |3 +--
volumes.c |4
13 files changed, 7 insertions(+), 127 deletions(-)
diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index a109c6a..8a12074 100644
--- a/btrfs-map-logical.c
+++ b/btrfs-map-logical.c
@@ -41,7 +41,6 @@ struct extent_buffer *debug_read_block(struct btrfs_root
*root, u64 bytenr,
u32 blocksize, int copy)
{
int ret;
- int dev_nr;
struct extent_buffer *eb;
u64 length;
struct btrfs_multi_bio *multi = NULL;
@@ -53,7 +52,6 @@ struct extent_buffer *debug_read_block(struct btrfs_root
*root, u64 bytenr,
if (!eb)
return NULL;
- dev_nr = 0;
length = blocksize;
while (1) {
ret = btrfs_map_block(&root->fs_info->mapping_tree, READ,
diff --git a/btrfsck.c b/btrfsck.c
index 63e44d1..e3cd435 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -1037,7 +1037,7 @@ static int process_one_leaf(struct btrfs_root *root,
struct extent_buffer *eb,
break;
};
}
- return 0;
+ return ret;
}
static void reada_walk_down(struct btrfs_root *root,
@@ -1917,7 +1917,6 @@ static int check_owner_ref(struct btrfs_root *root,
struct btrfs_root *ref_root;
struct btrfs_key key;
struct btrfs_path path;
- int ret;
int level;
int found = 0;
@@ -1950,7 +1949,7 @@ static int check_owner_ref(struct btrfs_root *root,
btrfs_init_path(&path);
path.lowest_level = level + 1;
- ret = btrfs_search_slot(NULL, ref_root, &key, &path, 0, 0);
+ btrfs_search_slot(NULL, ref_root, &key, &path, 0, 0);
if (buf->start == btrfs_node_blockptr(path.nodes[level + 1],
path.slots[level + 1]))
@@ -2539,16 +2538,6 @@ static int run_next_block(struct btrfs_root *root,
continue;
}
if (key.type == BTRFS_BLOCK_GROUP_ITEM_KEY) {
- struct btrfs_block_group_item *bi;
- bi = btrfs_item_ptr(buf, i,
- struct btrfs_block_group_item);
-#if 0
- fprintf(stderr,"block group %Lu %Lu used %Lu ",
- btrfs_disk_key_objectid(disk_key),
- btrfs_disk_key_offset(disk_key),
- btrfs_block_group_used(bi));
- fprintf(stderr, "flags %x\n", bi->flags);
-#endif
continue;
}
if (key.type == BTRFS_EXTENT_REF_V0_KEY) {
diff --git a/ctree.c b/ctree.c
index f70e10c..12f1a55 100644
--- a/ctree.c
+++ b/ctree.c
@@ -262,7 +262,6 @@ int __btrfs_cow_block(struct btrfs_trans_handle *trans,
struct extent_buffer **cow_ret,
u64 search_start, u64 empty_size)
{
- u64 generation;
struct extent_buffer *cow;
struct btrfs_disk_key disk_key;
int level;
@@ -272,7 +271,6 @@ int __btrfs_cow_block(struct btrfs_trans_handle *trans,
WARN_ON(root->ref_cows && trans->transid != root->last_trans);
level = btrfs_header_level(buf);
- generation = btrfs_header_generation(buf);
if (level == 0)
btrfs_item_key(buf, &di
[PATCH] btrfs: Handle SGID bit when creating inodes
Before this patch, new files/dirs would ignore the SGID bit on their
parent directory and always be owned by the creating user's uid/gid.
Signed-off-by: Chris Ball
---
fs/btrfs/inode.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ebd7d6c..ce25bb3 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3470,7 +3470,14 @@ static struct inode *btrfs_new_inode(struct
btrfs_trans_handle *trans,
root->highest_inode = objectid;
inode->i_uid = current_fsuid();
- inode->i_gid = current_fsgid();
+
+ if (dir->i_mode & S_ISGID) {
+ inode->i_gid = dir->i_gid;
+ if (S_ISDIR(mode))
+ mode |= S_ISGID;
+ } else
+ inode->i_gid = current_fsgid();
+
inode->i_mode = mode;
inode->i_ino = objectid;
inode_set_bytes(inode, 0);
--
1.6.1.2
--
Chris Ball
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[review] Btrfs: Allow shrinking close to used space
Hi,
This patch (against experimental HEAD) attempts to make shrinking more
robust, by only updating device size if we've succeeded in creating
enough free space without any failures in btrfs_relocate_chunk().
Here's a log with my patch applied. The two things to note are that a
near-limit shrink now works, and that a failed shrink (in this case,
trying to shrink to less than the used space) no longer updates the
device size erroneously:
http://dev.laptop.org/~cjb/btrfs/shrink-log
Please review carefully -- I'm still new to btrfs. The short version of
the patch is:
* create a success path, as a break out of the while(1) relocating
(rather than going to the "done" label).
* move the device size updating code into that path
* leave "path->reada = 2;" behind in the entry path, since path is
used by the searching operation rather than the later resize.
Thanks!
Signed-off-by: Chris Ball
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1316139..e2fa072 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1815,30 +1815,8 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
if (!path)
return -ENOMEM;
- trans = btrfs_start_transaction(root, 1);
- if (!trans) {
- ret = -ENOMEM;
- goto done;
- }
-
path->reada = 2;
- lock_chunks(root);
-
- device->total_bytes = new_size;
- if (device->writeable)
- device->fs_devices->total_rw_bytes -= diff;
- ret = btrfs_update_device(trans, device);
- if (ret) {
- unlock_chunks(root);
- btrfs_end_transaction(trans, root);
- goto done;
- }
- WARN_ON(diff > old_total);
- btrfs_set_super_total_bytes(super_copy, old_total - diff);
- unlock_chunks(root);
- btrfs_end_transaction(trans, root);
-
key.objectid = device->devid;
key.offset = (u64)-1;
key.type = BTRFS_DEV_EXTENT_KEY;
@@ -1867,7 +1845,7 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
length = btrfs_dev_extent_length(l, dev_extent);
if (key.offset + length <= new_size)
- goto done;
+ break;
chunk_tree = btrfs_dev_extent_chunk_tree(l, dev_extent);
chunk_objectid = btrfs_dev_extent_chunk_objectid(l, dev_extent);
@@ -1880,6 +1858,31 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
goto done;
}
+ /*
+* We've succeeded in freeing up enough space and can now update
+* the device's size.
+*/
+ trans = btrfs_start_transaction(root, 1);
+ if (!trans) {
+ ret = -ENOMEM;
+ goto done;
+ }
+
+ lock_chunks(root);
+ device->total_bytes = new_size;
+ if (device->writeable)
+ device->fs_devices->total_rw_bytes -= diff;
+ ret = btrfs_update_device(trans, device);
+ if (ret) {
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
+ goto done;
+ }
+ WARN_ON(diff > old_total);
+ btrfs_set_super_total_bytes(super_copy, old_total - diff);
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
+
done:
btrfs_free_path(path);
return ret;
--
Chris Ball
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [review] Btrfs: Allow shrinking close to used space
Hi,
Here's a new patch that incorporates these comments. We now update
device->fs_devices->total_rw_bytes before the shrink, as Josef suggests,
and create a new field in btrfs_device to store an on-disk size that is
only updated on a successful shrink operation, as requested by Yan.
(Thanks, Yan and Josef, for the patient explanations.)
==
From: Chris Ball
Btrfs: When shrinking, only update disk size on success
Previously, we updated a device's size prior to attempting a shrink
operation. This patch moves the device resizing logic to only happen if
the shrink completes successfully. In the process, it introduces a new
field to btrfs_device -- disk_total_bytes -- to track the on-disk size.
Signed-off-by: Chris Ball
---
fs/btrfs/volumes.c | 35 ---
fs/btrfs/volumes.h |3 +++
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1316139..303b7d6 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1433,7 +1433,7 @@ static noinline int btrfs_update_device(struct
btrfs_trans_handle *trans,
btrfs_set_device_io_align(leaf, dev_item, device->io_align);
btrfs_set_device_io_width(leaf, dev_item, device->io_width);
btrfs_set_device_sector_size(leaf, dev_item, device->sector_size);
- btrfs_set_device_total_bytes(leaf, dev_item, device->total_bytes);
+ btrfs_set_device_total_bytes(leaf, dev_item, device->disk_total_bytes);
btrfs_set_device_bytes_used(leaf, dev_item, device->bytes_used);
btrfs_mark_buffer_dirty(leaf);
@@ -1828,14 +1828,6 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
device->total_bytes = new_size;
if (device->writeable)
device->fs_devices->total_rw_bytes -= diff;
- ret = btrfs_update_device(trans, device);
- if (ret) {
- unlock_chunks(root);
- btrfs_end_transaction(trans, root);
- goto done;
- }
- WARN_ON(diff > old_total);
- btrfs_set_super_total_bytes(super_copy, old_total - diff);
unlock_chunks(root);
btrfs_end_transaction(trans, root);
@@ -1867,7 +1859,7 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
length = btrfs_dev_extent_length(l, dev_extent);
if (key.offset + length <= new_size)
- goto done;
+ break;
chunk_tree = btrfs_dev_extent_chunk_tree(l, dev_extent);
chunk_objectid = btrfs_dev_extent_chunk_objectid(l, dev_extent);
@@ -1880,6 +1872,26 @@ int btrfs_shrink_device(struct btrfs_device *device, u64
new_size)
goto done;
}
+ /* Shrinking succeeded, else we would be at "done". */
+ trans = btrfs_start_transaction(root, 1);
+ if (!trans) {
+ ret = -ENOMEM;
+ goto done;
+ }
+ lock_chunks(root);
+
+ device->disk_total_bytes = new_size;
+ /* Now btrfs_update_device() will change the on-disk size. */
+ ret = btrfs_update_device(trans, device);
+ if (ret) {
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
+ goto done;
+ }
+ WARN_ON(diff > old_total);
+ btrfs_set_super_total_bytes(super_copy, old_total - diff);
+ unlock_chunks(root);
+ btrfs_end_transaction(trans, root);
done:
btrfs_free_path(path);
return ret;
@@ -2959,7 +2971,8 @@ static int fill_device_from_item(struct extent_buffer
*leaf,
unsigned long ptr;
device->devid = btrfs_device_id(leaf, dev_item);
- device->total_bytes = btrfs_device_total_bytes(leaf, dev_item);
+ device->disk_total_bytes = btrfs_device_total_bytes(leaf, dev_item);
+ device->total_bytes = device->disk_total_bytes;
device->bytes_used = btrfs_device_bytes_used(leaf, dev_item);
device->type = btrfs_device_type(leaf, dev_item);
device->io_align = btrfs_device_io_align(leaf, dev_item);
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index 86c44e9..bf1ba75 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -52,6 +52,9 @@ struct btrfs_device {
/* size of the device */
u64 total_bytes;
+ /* size of the disk */
+ u64 disk_total_bytes;
+
/* bytes used */
u64 bytes_used;
--
1.6.1.3
- Chris.
--
Chris Ball
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: Add an alarm for long-running transactions.
If we're waiting for a transaction to end, and it started more than five
minutes ago, emit a warning.
Signed-off-by: Chris Ball
---
fs/btrfs/transaction.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index f94c2ad..9fa477c 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -80,6 +80,7 @@ static noinline int join_transaction(struct btrfs_root *root)
root->fs_info->running_transaction = cur_trans;
spin_unlock(&root->fs_info->new_trans_lock);
} else {
+ WARN_ON_ONCE(get_seconds() - cur_trans->start_time > 300);
cur_trans->num_writers++;
cur_trans->num_joined++;
}
--
1.6.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add a "-v" flag for verbose scanning, and ignore floppy devices.
A user on IRC reported that btrfsctl -a appeared to hang -- this was
because it was trying to read the fd0 floppy device, and getting I/O
errors back. This patch introduces "btrfsctl -a -v" to print device
names as they are scanned, and ignores devices with the floppy major
device ID (2).
Signed-off-by: Chris Ball
---
btrfs-show.c |2 +-
btrfsctl.c | 11 ---
utils.c | 17 +++--
utils.h |2 +-
4 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/btrfs-show.c b/btrfs-show.c
index c49626c..91e0e43 100644
--- a/btrfs-show.c
+++ b/btrfs-show.c
@@ -133,7 +133,7 @@ int main(int ac, char **av)
search = av[optind];
}
- ret = btrfs_scan_one_dir("/dev", 0);
+ ret = btrfs_scan_one_dir("/dev", 0, 0);
if (ret)
fprintf(stderr, "error %d while scanning\n", ret);
diff --git a/btrfsctl.c b/btrfsctl.c
index b323818..e0193f2 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -46,7 +46,7 @@ static inline int ioctl(int fd, int define, void *arg) {
return 0; }
static void print_usage(void)
{
printf("usage: btrfsctl [ -d file|dir] [ -s snap_name subvol|tree ]\n");
- printf("[-r size] [-A device] [-a] [-c]\n");
+ printf("[-r size] [-A device] [-a] [-c] [-v]\n");
printf("\t-d filename: defragments one file\n");
printf("\t-d directory: defragments the entire Btree\n");
printf("\t-s snap_name dir: creates a new snapshot of dir\n");
@@ -55,6 +55,7 @@ static void print_usage(void)
printf("\t-A device: scans the device file for a Btrfs filesystem\n");
printf("\t-a: scans all devices for Btrfs filesystems\n");
printf("\t-c: forces a single FS sync\n");
+ printf("\t-v: verbose output while scanning devices\n");
printf("%s\n", BTRFS_BUILD_VERSION);
exit(1);
}
@@ -100,10 +101,14 @@ int main(int ac, char **av)
unsigned long command = 0;
int len;
char *fullpath;
+ int verbose = 0;
- if (ac == 2 && strcmp(av[1], "-a") == 0) {
+ if (ac == 3 && strcmp(av[2], "-v") == 0)
+ verbose = 1;
+
+ if ((ac == 2 || ac == 3) && strcmp(av[1], "-a") == 0) {
fprintf(stderr, "Scanning for Btrfs filesystems\n");
- btrfs_scan_one_dir("/dev", 1);
+ btrfs_scan_one_dir("/dev", 1, verbose);
exit(0);
}
for (i = 1; i < ac; i++) {
diff --git a/utils.c b/utils.c
index a87c5a8..1f38a82 100644
--- a/utils.c
+++ b/utils.c
@@ -41,6 +41,8 @@
#include "volumes.h"
#include "ioctl.h"
+#define MAJOR(x) (((x)>>8)&0xff)
+
#ifdef __CHECKER__
#define BLKGETSIZE64 0
static inline int ioctl(int fd, int define, u64 *size) { return 0; }
@@ -663,7 +665,7 @@ void btrfs_register_one_device(char *fname)
close(fd);
}
-int btrfs_scan_one_dir(char *dirname, int run_ioctl)
+int btrfs_scan_one_dir(char *dirname, int run_ioctl, int verbose)
{
DIR *dirp = NULL;
struct dirent *dirent;
@@ -735,6 +737,17 @@ again:
fprintf(stderr, "failed to read %s\n", fullpath);
continue;
}
+
+ if (MAJOR(st.st_rdev) == 2) {
+ if (verbose)
+ fprintf(stderr, "Skipping floppy device %s\n",
+ fullpath);
+ continue;
+ }
+
+ if (verbose)
+ fprintf(stderr, "Scanning %s\n", fullpath);
+
ret = btrfs_scan_one_device(fd, fullpath, &tmp_devices,
&num_devices,
BTRFS_SUPER_INFO_OFFSET);
@@ -762,7 +775,7 @@ fail:
int btrfs_scan_for_fsid(struct btrfs_fs_devices *fs_devices, u64 total_devs,
int run_ioctls)
{
- return btrfs_scan_one_dir("/dev", run_ioctls);
+ return btrfs_scan_one_dir("/dev", run_ioctls, 0);
}
int btrfs_device_already_in_root(struct btrfs_root *root, int fd,
diff --git a/utils.h b/utils.h
index 7ff542b..a85ba41 100644
--- a/utils.h
+++ b/utils.h
@@ -35,7 +35,7 @@ int btrfs_add_to_fsid(struct btrfs_trans_handle *trans,
int btrfs_scan_for_fsid(struct btrfs_fs_devices *fs_devices, u64 total_devs,
int run_ioctls);
void btrfs_register_one_device(char *fname);
-int btrfs_scan_one_dir(char *dirname, int run_ioctl);
+int btrfs_scan_one_dir(char *dirname, int run_ioctl, int verbose);
int check_mounted(char *devicename);
int btrfs_device_already_in_root(struct btrfs_root *root, int fd,
int super_offset);
--
1.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW] Btrfs: Introduce ioctl for compressed size of file
btrfs_item_nr(leaf, slot));
+ }
+ btrfs_release_path(root, path);
+ }
+
+ btrfs_release_path(root, path);
+ key.offset++;
+ }
+
+ /* We've succeeded in going through all extents; set the final size. */
+ ret = compressed_size;
+
+out:
+ btrfs_release_path(root, path);
+ unlock_extent(&BTRFS_I(inode)->io_tree, 0, len, GFP_NOFS);
+ mutex_unlock(&inode->i_mutex);
+ btrfs_free_path(path);
+ return ret;
+}
+
static long btrfs_ioctl_clone_range(struct file *file, void __user *argp)
{
struct btrfs_ioctl_clone_range_args args;
@@ -1122,6 +1233,8 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_trans_start(file);
case BTRFS_IOC_TRANS_END:
return btrfs_ioctl_trans_end(file);
+ case BTRFS_IOC_COMPR_SIZE:
+ return btrfs_ioctl_compsize(file);
case BTRFS_IOC_SYNC:
btrfs_sync_fs(file->f_dentry->d_sb, 1);
return 0;
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index b320b10..bd2f866 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -66,4 +66,5 @@ struct btrfs_ioctl_clone_range_args {
#define BTRFS_IOC_SUBVOL_CREATE _IOW(BTRFS_IOCTL_MAGIC, 14, \
struct btrfs_ioctl_vol_args)
+#define BTRFS_IOC_COMPR_SIZE _IO(BTRFS_IOCTL_MAGIC, 15)
#endif
--
Chris Ball
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] btrfs: implement FS_IOC_GETFLAGS/SETFLAGS/GETVERSION
Hi Christoph, > Add support for the standard attributes set via chattr and read > vis lsattr. Currently we store the attributes in the flags value > in the btrfs inode, but I wonder whether we should split it into > two so that we don't have to keep converting between the two > formats. Any thoughts on how best to add support for setting the custom btrfs flags (nodatasum/nodatacow/nocompress) via an ioctl? Is it possible to reuse FS_IOC_SETFLAGS for these too, or do we need a new ioctl? If we need a new one, any preference between an ioctl per flag vs. a single ioctl that accepts a new set of flags? Thanks, - Chris. -- Chris Ball -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does stat() return invalid st_dev field for btrfs ??
Hi, > Mmm.. btrfs appears to configure itself as a "pseudo" filesystem, > which is why it returns fake device numbers via stat(), similar > to procfs or sysfs. Probably because a single btrfs filesystem can be composed of multiple devices; one major/minor would not be sufficient. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Btrfs: Use CONFIG_BTRFS_POSIX_ACL to enable ACL code
We've already defined CONFIG_BTRFS_POSIX_ACL in Kconfig, but we're
currently not using it and are testing CONFIG_FS_POSIX_ACL instead.
CONFIG_FS_POSIX_ACL states "Never use this symbol for ifdefs".
Signed-off-by: Chris Ball
---
fs/btrfs/acl.c |6 +++---
fs/btrfs/ctree.h |2 +-
fs/btrfs/xattr.c |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/acl.c b/fs/btrfs/acl.c
index f128427..69b355a 100644
--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -27,7 +27,7 @@
#include "btrfs_inode.h"
#include "xattr.h"
-#ifdef CONFIG_FS_POSIX_ACL
+#ifdef CONFIG_BTRFS_POSIX_ACL
static struct posix_acl *btrfs_get_acl(struct inode *inode, int type)
{
@@ -313,7 +313,7 @@ struct xattr_handler btrfs_xattr_acl_access_handler = {
.set= btrfs_xattr_acl_access_set,
};
-#else /* CONFIG_FS_POSIX_ACL */
+#else /* CONFIG_BTRFS_POSIX_ACL */
int btrfs_acl_chmod(struct inode *inode)
{
@@ -325,4 +325,4 @@ int btrfs_init_acl(struct inode *inode, struct inode *dir)
return 0;
}
-#endif /* CONFIG_FS_POSIX_ACL */
+#endif /* CONFIG_BTRFS_POSIX_ACL */
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 837435c..22b9a84 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2317,7 +2317,7 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options);
int btrfs_sync_fs(struct super_block *sb, int wait);
/* acl.c */
-#ifdef CONFIG_FS_POSIX_ACL
+#ifdef CONFIG_BTRFS_POSIX_ACL
int btrfs_check_acl(struct inode *inode, int mask);
#else
#define btrfs_check_acl NULL
diff --git a/fs/btrfs/xattr.c b/fs/btrfs/xattr.c
index a9d3bf4..b0fc93f 100644
--- a/fs/btrfs/xattr.c
+++ b/fs/btrfs/xattr.c
@@ -260,7 +260,7 @@ err:
* attributes are handled directly.
*/
struct xattr_handler *btrfs_xattr_handlers[] = {
-#ifdef CONFIG_FS_POSIX_ACL
+#ifdef CONFIG_BTRFS_POSIX_ACL
&btrfs_xattr_acl_access_handler,
&btrfs_xattr_acl_default_handler,
#endif
--
1.6.4
--
Chris Ball
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Btrfs: Fix setting umask when POSIX ACLs are not enabled
We currently set sb->s_flags |= MS_POSIXACL unconditionally, which is incorrect -- it tells the VFS that it shouldn't set umask because we will, yet we don't set it ourselves if we aren't using POSIX ACLs, so the umask ends up ignored. Signed-off-by: Chris Ball --- fs/btrfs/super.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 6d6d06c..48ed1c0 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -344,7 +344,9 @@ static int btrfs_fill_super(struct super_block *sb, sb->s_export_op = &btrfs_export_ops; sb->s_xattr = btrfs_xattr_handlers; sb->s_time_gran = 1; +#ifdef CONFIG_BTRFS_POSIX_ACL sb->s_flags |= MS_POSIXACL; +#endif tree_root = open_ctree(sb, fs_devices, (char *)data); -- 1.6.4 -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel oops with 2.6.31 in btrfs_set_acl
Hi, > Hi, I got an oops this morning with btrfs on the Ubuntu 2.6.31 > kernel. I mounted with compress and thread_pool=4. This is on a > 64 bit quad AMD machine. > > [614439.132228] [] ? btrfs_set_acl+0x87/0x230 Could you tell us what line of the source code that is? This should work, after gdb btrfs.ko: (gdb) list *btrfs_set_acl+0x87 - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Building a RAID post-mkfs?
Hi, I installed btrfs to one disk using the Fedora 12 installer; it doesn't allow any configuration of the mkfs command by the user, so it wasn't possible to mkfs with more than one disk. I'd like to add a second disk, with either RAID0 or RAID1 between the two -- the equivalent of "mkfs.btrfs -m raid0/1 -d raid0/1 /dev/sda /dev/sdb". Is it possible to create this non-destructively now? If not, should it be? What would the implementation look like? Thanks, - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: List of devices added to a btrfs file system
Hi Prasad, > This works really fine, but there should be a way to list the > number of device and device names added to the file system. Is > there any way to get that list? btrfs-show does this. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rootfs snapshots and rollback (i.e. testing updates)
Hi, > Is it possible, with current btrfs: Yes, I think so. > - to take a rootfs snapshot (i.e. prior to a major update), btrfsctl -s newsnap / > - do changes in the root filesystem (i.e. install major update), > > - if we don't like what the major update did to the system > (rootfs), "rollback" the snapshot and make it the "original" > rootfs again (perhaps, with a reboot in between). Before rebooting, edit whatever mounts your root partition (initrd, fstab, kernel argument) to add a "subvol=newsnap" mount argument. An obvious way to make this nicer would be to: * have the package manager create the snapshot before modifying the system, with a timestamp. * modify the bootloader to give a choice of snapshots at boot-time. Note that you're rolling back *all* rootfs changes, not merely the changes that the package manager made, so it wouldn't be correct to think of this as a way to only rollback package manager transactions. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: Btrfs snapshots feature proposal for Fedora 13
Hi, I've written up a draft of an Fedora 13 feature proposal for filesystem rollback using Btrfs snapshots that are automatically created by yum: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs It'd be great to get feedback on whether this is a good idea, and how the UI interaction should work. We're also discussing it in this fedora-devel thread: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/123695 Some comments I've got already received, from the thread: * People want the UI to allow independent active snapshots per filesystem (i.e. btrfs /home is the live filesystem, and btrfs / is an older snapshot). * Several people think that the ZFS Time Slider patches to nautilus¹ look good, and want that for btrfs. Sounds plausible, but I'm more interested in first working on ways to let developers feel comfortable upgrading to the development version of Fedora each day with the possibility of reverting. * Instead of inventing a new system-config-blah, this should probably be part of Palimpsest². * Perhaps we should encourage people using the Fedora installer with btrfs to create a rootfs separate to their /home, so that they can rollback rootfs snapshots without affecting their homedir. Thanks! - Chris. ¹: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs http://blogs.sun.com/erwann/entry/time_slider_screencast http://blogs.sun.com/erwann/entry/new_time_slider_features_in ²: http://library.gnome.org/users/palimpsest/stable/intro.html.en -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mount via /etc/fstab constant failure
Hi Reg, > Hi, I have a btrfs 'pool' of x2 Samsung 500GB HDD's in non-raid > format. It works fine for the most part except for mounting on > bootup. Every bootup I have to change the block-device to and fro > /dev/sda & /dev/sdb. This happens on linux-2.6.32.2 and > 2.6.33-rc2. Are you running "btrfsctl -a" in an initrd? It's necessary to do that before the mount call on a multi-disk volume. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug] Reclaim space.
Hi,
> Hi, I assume this has something to do with using updated btrfs
> and old btrfs utils, but it's only the presentation that is
> wrong.
Yes, this wouldn't happen with latest btrfs-progs.
> But df -h gives:
> /dev/mapper/root145G -64Z -122G 100% /
Here's a patch to btrfsck from Josef that should fix this:
Signed-off-by: Josef Bacik
---
btrfsck.c | 30 ++
ctree.h |1 +
extent-tree.c | 32
3 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/btrfsck.c b/btrfsck.c
index 46a6eae..77db11a 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -2805,6 +2805,34 @@ static int check_extents(struct btrfs_root *root)
return ret;
}
+static void check_space_used(struct btrfs_root *root)
+{
+ struct btrfs_fs_info *info = root->fs_info;
+ u64 total;
+ u64 super_total;
+
+ total = btrfs_total_used(root);
+ super_total = btrfs_super_bytes_used(&info->super_copy);
+
+ if (total != super_total) {
+ struct btrfs_trans_handle *trans;
+
+ trans = btrfs_start_transaction(root, 1);
+ if (!trans)
+ return;
+ printf("Super total bytes used (%llu) doesn't match actual "
+ "bytes used (%llu). Fixing.\n",
+ (unsigned long long)super_total,
+ (unsigned long long)total);
+ btrfs_set_super_bytes_used(&info->super_copy, total);
+ btrfs_commit_transaction(trans, root);
+ } else {
+ printf("Super total bytes used (%llu) matches actual (%llu)\n",
+ (unsigned long long)super_total,
+ (unsigned long long)total);
+ }
+}
+
static void print_usage(void)
{
fprintf(stderr, "usage: btrfsck dev\n");
@@ -2836,6 +2864,8 @@ int main(int ac, char **av)
goto out;
ret = check_root_refs(root, &root_cache);
+ if (!ret)
+ check_space_used(root);
out:
free_root_recs(&root_cache);
close_ctree(root);
diff --git a/ctree.h b/ctree.h
index a9062ea..89eb0b9 100644
--- a/ctree.h
+++ b/ctree.h
@@ -1699,6 +1699,7 @@ int btrfs_make_block_group(struct btrfs_trans_handle
*trans,
struct btrfs_root *root, u64 bytes_used,
u64 type, u64 chunk_objectid, u64 chunk_offset,
u64 size);
+u64 btrfs_total_used(struct btrfs_root *root);
int btrfs_make_block_groups(struct btrfs_trans_handle *trans,
struct btrfs_root *root);
int btrfs_update_block_group(struct btrfs_trans_handle *trans,
diff --git a/extent-tree.c b/extent-tree.c
index e1d7ffd..478807c 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -3135,6 +3135,38 @@ error:
return ret;
}
+u64 btrfs_total_used(struct btrfs_root *root)
+{
+ struct btrfs_block_group_cache *cache;
+ struct extent_io_tree *block_group_cache;
+ int ret;
+ u64 ptr;
+ u64 start;
+ u64 end;
+ u64 total = 0;
+
+ block_group_cache = &root->fs_info->block_group_cache;
+ start = BTRFS_SUPER_INFO_OFFSET + BTRFS_SUPER_INFO_SIZE;
+ while (1) {
+ ret = find_first_extent_bit(block_group_cache,
+ start, &start, &end,
+ BLOCK_GROUP_DATA |
+ BLOCK_GROUP_METADATA |
+ BLOCK_GROUP_SYSTEM);
+ if (ret)
+ break;
+ ret = get_state_private(block_group_cache, start, &ptr);
+ if (ret)
+ break;
+
+ cache = (struct btrfs_block_group_cache *)(unsigned long)ptr;
+ total += btrfs_block_group_used(&cache->item);
+ start = end + 1;
+ }
+
+ return total;
+}
+
int btrfs_make_block_group(struct btrfs_trans_handle *trans,
struct btrfs_root *root, u64 bytes_used,
u64 type, u64 chunk_objectid, u64 chunk_offset,
--
1.5.4.3
--
Chris Ball
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug] Reclaim space.
int verify);
int btrfs_read_buffer(struct extent_buffer *buf, u64 parent_transid);
+int btrfs_make_readwrite(struct btrfs_fs_info *fs_info);
+int btrfs_make_readonly(struct btrfs_fs_info *fs_info);
#endif
diff --git a/extent-tree.c b/extent-tree.c
index e1d7ffd..49bffe7 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -3135,6 +3135,68 @@ error:
return ret;
}
+void btrfs_update_block_groups_readonly(struct btrfs_fs_info *info)
+{
+ struct btrfs_block_group_cache *cache;
+ struct extent_io_tree *block_group_cache;
+ int ret;
+ u64 ptr;
+ u64 start;
+ u64 end;
+
+ block_group_cache = &info->block_group_cache;
+ start = BTRFS_SUPER_INFO_OFFSET + BTRFS_SUPER_INFO_SIZE;
+ while (1) {
+ ret = find_first_extent_bit(block_group_cache,
+ start, &start, &end,
+ BLOCK_GROUP_DATA |
+ BLOCK_GROUP_METADATA |
+ BLOCK_GROUP_SYSTEM);
+ if (ret)
+ break;
+ ret = get_state_private(block_group_cache, start, &ptr);
+ if (ret)
+ break;
+
+ cache = (struct btrfs_block_group_cache *)(unsigned long)ptr;
+ cache->ro = btrfs_chunk_readonly(info->extent_root,
+cache->key.objectid);
+ start = end + 1;
+ }
+}
+
+u64 btrfs_total_used(struct btrfs_root *root)
+{
+ struct btrfs_block_group_cache *cache;
+ struct extent_io_tree *block_group_cache;
+ int ret;
+ u64 ptr;
+ u64 start;
+ u64 end;
+ u64 total = 0;
+
+ block_group_cache = &root->fs_info->block_group_cache;
+ start = BTRFS_SUPER_INFO_OFFSET + BTRFS_SUPER_INFO_SIZE;
+ while (1) {
+ ret = find_first_extent_bit(block_group_cache,
+ start, &start, &end,
+ BLOCK_GROUP_DATA |
+ BLOCK_GROUP_METADATA |
+ BLOCK_GROUP_SYSTEM);
+ if (ret)
+ break;
+ ret = get_state_private(block_group_cache, start, &ptr);
+ if (ret)
+ break;
+
+ cache = (struct btrfs_block_group_cache *)(unsigned long)ptr;
+ total += btrfs_block_group_used(&cache->item);
+ start = end + 1;
+ }
+
+ return total;
+}
+
int btrfs_make_block_group(struct btrfs_trans_handle *trans,
struct btrfs_root *root, u64 bytes_used,
u64 type, u64 chunk_objectid, u64 chunk_offset,
--
1.5.4.3
--
Chris Ball
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug] Reclaim space.
Hi, > Will this also fix the directory that i can't delete? No, I think you need "btrfsctl -D" for that. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug] Reclaim space.
Hi, > btrfsctl -D ext2_saved/ > ioctl:: Invalid argument It's merged (during 2.6.32) -- I think you just have the wrong syntax. See http://btrfs.wiki.kernel.org/index.php/Btrfsctl. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using snapshots as quick restore point
Hi, > * create snapshot > * mount it somewhere (read-write) > * operate on the snapshot, change some files etc... > * revert changes made to the snapshot to its original state Make two snapshots instead of one, and only modify one of them? Because of CoW, new snapshots have very low overhead. > with or without unmounting it. You would have to unmount it if it had any open files. > If not, is there any filesystem that can do that ? I don't know of any filesystem that lets you discard changes to a snapshot, but I've just described a method for doing so where you always make a read-only -pristine version of that snapshot and have tools that base your read-write snapshots on that. I don't think it would be possible for any filesystem to handle changing snapshot on a mounted filesystem with files open, so it makes sense that it's a remount operation. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zero-length files in snapshots
Hi, > I often get zero-length files in btrfs snapshots (when the > original files were not zero-length). The shell script below > reproduces this problem on two Ubuntu machines, with Ubuntu > kernels 2.6.31-17.54 and 2.6.32-12.17. Is there some mistaken > assumption I'm making here in terms of how btrfsctl works? > [..] > > echo x1 > /mnt/x/d/foo.txt || exit 2 > btrfsctl -s /mnt/x/snap /mnt/x/d You're just missing a sync/fsync() between these two lines. We argued on IRC a while ago about whether this is a sensible default; cmason wants the no-sync version of snapshot creation to be available, but was amenable to the idea of changing the default to be sync before snapshot, since it was pointed out that no-one other than him had understood we were supposed to be running sync first. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zero-length files in snapshots
Hi, > Is there a race in there? It seems like if a process starts > modifying a file between the sync and the snapshot, data could > still be lost. Is there something else going on here that I'm > missing that would prevent this race? AIUI, you're correct that a writer process concurrent to a snapshot leads to a race with data that doesn't make it in to the snapshot, but I think you're wrong in thinking that there's much we could do about it -- either you miss writes between sync and snapshot, as we do now, or we do sync-and-snapshot atomically, and the concurrent writes are missed because we decided to block further writes from that process before we took the snapshot. The only real answer is to quiesce the writer process before you begin. Does that make sense? - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Raid1 with 3 drives
Hi, > DF with btrfs is a loaded question. In the RAID1 case you are > going to show 3TB of free space, but everytime you use some space > you are going to show 3 times the amount used (I think thats > right). There are some patches forthcoming to make the reporting > for RAID stuff make more sense, but for the time being just > ignore df. Added to: http://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F since we're often seeing this question on the list and IRC. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cross-subvolume link causes kernel BUG
Hi, > ln segfaults, and the bug above is found in dmesg. Subsequent > accesses to the subvolume result in a D state hung process. Full > dmesg follows. I first observed this on a Gentoo system and > reproduced it on Ubuntu. Both were running unpatched 2.6.32.9 > kernels. I think this is fixed in 2.6.33, as a result of the patch below. Let us know if you see a segfault on 2.6.33, or after applying this patch to your current kernel. Thanks, - Chris. commit 4a8be425a8fb8fbb5d881eb55fa6634c3463b9c9 Author: TARUISI Hiroaki Date: Thu Nov 12 07:14:26 2009 + Btrfs: deny sys_link across subvolumes. I rebased Christian Parpart's patch to deny hard link across subvolumes. Original patch modifies also btrfs_rename, but I excluded it because we can move across subvolumes now and it make no problem. - Hard link across subvolumes should not allowed in Btrfs. btrfs_link checks root of 'to' directory is same as root of 'from' file. If not same, btrfs_link returns -EPERM. Signed-off-by: TARUISI Hiroaki Signed-off-by: Chris Mason diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 168e8c0..da76cad 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4462,6 +4462,10 @@ static int btrfs_link(struct dentry *old_dentry, struct inode *dir, if (inode->i_nlink == 0) return -ENOENT; + /* do not allow sys_link's with other subvols of the same device */ + if (root->objectid != BTRFS_I(inode)->root->objectid) + return -EPERM; + /* * 1 item for inode ref * 2 items for dir items -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: default subvolume abilities/restrictions
Hi, > moving along to a question... can the default subvolume be > swapped/removed/renamed/popped/shifted? I think "btrfs subvolume list; btrfs subvolume set-default " does what you need. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: raid1 not reporting the right size
Hi, > I'm trying to create a raid1 (mirrored) raid using two 1 Tb > disks. The result is something twice as large as it should be > fore mirrored raid. https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_free_space_for_my_RAID_volume.3F -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: can subvolumes be specified as compressed?
Hi, > So, is there such a method: in a specified directory, the > compression feature is enabled, and the file in this directory > will be compressed automatically, while the others don't enable > compression. I don't think so, but it wouldn't be difficult -- you'd just set a per-inode flag on whether to compress, and if it's set on a directory then it's inherited by the files in that directory. I think the hold up has been that we've waited for a *generic* cross-filesystem flag to appear, and it hasn't (or it has and I didn't notice). Does anyone have suggestions on how to break the deadlock there? - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: can subvolumes be specified as compressed?
Hi, > I don't know whether this demand, which specified some subvolumes > or directories to be compressed, conflict with the design of > btrfs's compression feature, may be they want to do this thing > well, and everyone will enable the compression feature, rather > than throw the decision to user to determine which should > compress. You can't tell whether you can compress data well until you've already spent CPU compressing it, though. Right now we have a useful metric of "if parts of the file fail to compress, bail out on compressing the rest of the file, both now and in the future"; but it's only a metric. There are cases this fails on, such as a tar archive that starts out with JPEGs and continues with large (compressible) text files. I think the argument that we don't need to offer user control because we can just do a good job all the time only works if it's actually true that we can do a good job all the time, and I don't think that's true here. So, I still support user control of the per-inode flag. (I agree about the subvol flags; I think being able to set quotas and compression per-subvol is on the roadmap and just not done yet.) -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
Hi, > the other big question is: > > Is btrfs with 2.6.36 really rockstable and ready to use in > productive environments? No, certainly not until there's a working fsck tool -- at the moment it's rather easy to kill a btrfs by just losing power. I just added a paragraph to the main page of the wiki about this, since we've had a few people on IRC express surprise that their filesystem aren't fixable after power loss. Feel free to reword: Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power. This will be fixed when the fsck tool is ready. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36-rc1 btrfs still unstable
Hi, > I don't think the signboards are big enough. Sure; that's why I tried to make one of them larger. > Most people assume that there is some way of fixing a broken file > system, and finding out the btrfs does not have one usually is > quite surprising and just a little too late. Agreed, that's my experience from the IRC channel. > I was under the impression that with atomic writes it's > impossible to mess up a file system? Yes, we're not seeing data corruption, we're correctly reporting that the transid of the data block doesn't match the transid in the parent node's pointer, which means that some writes went missing. Then we're hitting a BUG() as a result, which hangs. I don't know what the right way of dealing with this is going to be, but answers like "pretend the lost writes never happened and sync the transids", or "do something other than BUG() on verify_parent_transid() failure" sound plausible. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updating the wiki pages adding btrfs command
Hi, > adding a --wait or --sync switch to the delete command is > certainly possible, you'd want to add it to the last in a series > of deletes. I think this (--sync) is a much better idea than the alternatives so far. Thanks, -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updating the wiki pages adding btrfs command
Hi, > Or make --sync the default behavior. This is probably what most > people are expecting anyway (similar to how standard filesystem > commands like "rm" work). Add an --aysnc option for those that > only care about knowing when the subvolume is taken out of the > tree. Yeah. We've also talked about making snapshot _creation_ perform an FS sync first by default, since otherwise you get a snapshot with stale files, or without files that existed (not yet on disk) at creation-time. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Updating the wiki pages adding btrfs command
Hi Sage, > Actually, that was fixed in 2.6.34 (0bdb1db2). Creating a > snapshot syncs all dirty data and metadata to disk, so you get a > fully consistent point in time snapshot. No 'sync' is necessary > (and doing a 'sync' yourself would be racy any). Oh, thanks! Am happy to see that. > Why not just do: > # btrfs subvolume delete /path/to/subvolume1 > # btrfs subvolume delete /path/to/subvolume2 > # sync Or even better, "btrfs filesystem sync ". I'm assuming that the caller wants to wait until the subvol delete has happened, but is unwilling to wait until all other writes to the FS have finished, and is even more unwilling to wait for all writes on the rest of the system to finish. I don't know whether that's actually a reasonable/plausible use case, though. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add the "btrfs filesystem label" command
Hi, > How can one char equal two chars? > > input[i] == '\\' If the first char is the C escape sequence for string literals. :) - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs user survey?
Hi Francis, > Well, all in all, you get the idea, and I'm probably not the guy > to craft questions for such a survey. But having input from as > large a panel of users as possible would be a nice thing to have. Your questions are fine -- I might add: * Rank the following future features in importance, 4 == most important [ ] working fsck [ ] GUIs for userspace actions e.g. snapshots [ ] data deduplication [ ] hot data relocation Please use something like Google Spreadsheets (which has a forms option) if you're going to run such a survey, rather than having everyone reply on-list -- we shouldn't bother this list with any results other than the final summary. - Chris. -- Chris Ball One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
