Re: [PATCH] Btrfs: simplify iteration codes
On Fri, Jan 16, 2009 at 3:25 PM, Qinghuang Feng wrote: > merge list_for_each and list_entry to list_for_each_entry. > Please ignore this patch, I will resend a patch to cleanup all the similar codes in btrfs. -- 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: [GIT PULL] adaptive spinning mutexes
> I'll kick off some runs of my three benchmarks on ext3 for comparison. > If there are things less synthetic people would like to see, please let > me know. What about a web-server test? Number of hits per second it can do? Folkert van Heusden -- MultiTail er et flexible tool for å kontrolere Logfiles og commandoer. Med filtrer, farger, sammenføringer, forskeliger ansikter etc. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com -- 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: [GIT PULL] adaptive spinning mutexes
> > I'll kick off some runs of my three benchmarks on ext3 for comparison. > > If there are things less synthetic people would like to see, please let > > me know. > > What about a web-server test? Number of hits per second it can do? Quick hack: http://vanheusden.com/tortureweb/tortureweb-0.1.tgz To test multiple requesters, start this program multiple times in parallel. There are probably better testers but for a quick test and might be sufficient. Folkert van Heusden -- Multitail es una herramienta flexible que permite visualizar los "log file" y seguir la ejecución de comandos. Permite filtrar, añadir colores, combinar archivos, la visualización de diferencias (diff- view), etc. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com -- 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: [GIT PULL] adaptive spinning mutexes
> So I don't dispute at all that "mutex with spinning" performs better than > a mutex, but I _do_ claim that it has some potentially huge downsides > compared to a real spinlock. It may perform as well as a spinlock in the > nice common case, but then when you hit the non-common case you see the > difference between well-written code and badly written code. Make it mount-point dependant. Then your mail-spool can use the spinlock version and e.g. the /usr filesystem uses regular mutexes. Might be tricky to implement I guess. Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff- view', vs. http://www.vanheusden.com/multitail/ -- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com -- 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: simplify iteration codes
On Fri, 2009-01-16 at 15:25 +0800, Qinghuang Feng wrote: > merge list_for_each and list_entry to list_for_each_entry. > Thanks, I've queued this up. -chris -- 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: simplify iteration codes
On Fri, Jan 16, 2009 at 10:31 PM, Chris Mason wrote: > On Fri, 2009-01-16 at 15:25 +0800, Qinghuang Feng wrote: >> merge list_for_each and list_entry to list_for_each_entry. >> > > Thanks, I've queued this up. > Good, but Now I have made a new patch for cleanupping all the similar codes in btrfs. This patch has been tested in VM, it seems ok. Now should I rebuild another patch which based the previous patch, or could you be able to reverse the previous patch then I just post this new patch including all stuff? Sorry I am not much familiar with the posting flow, and I am not sure the meaning of "queued". -- 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: simplify iteration codes
On Fri, 2009-01-16 at 23:20 +0800, sniper wrote: > On Fri, Jan 16, 2009 at 10:31 PM, Chris Mason wrote: > > On Fri, 2009-01-16 at 15:25 +0800, Qinghuang Feng wrote: > >> merge list_for_each and list_entry to list_for_each_entry. > >> > > > > Thanks, I've queued this up. > > > Good, but > > Now I have made a new patch for cleanupping all the similar codes in btrfs. > This patch has been tested in VM, it seems ok. > > Now should I rebuild another patch which based the previous patch, > or could you be able to reverse the previous patch then I just post > this new patch including all stuff? > > Sorry I am not much familiar with the posting flow, and I am not sure > the meaning of "queued". It means this one looks right and I've put it into my internal testing tree. It should be in my next pull request. But, I'll hold off on this one if there is a larger set of fixes coming that contain it. -chris -- 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 resend] Btrfs: simplify iteration codes
Merge list_for_each* and list_entry to list_for_each_entry*
Signed-off-by: Qinghuang Feng
---
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 81a3138..aedfcec 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1136,7 +1136,6 @@ static int btrfs_congested_fn(void *congested_data, int
bdi_bits)
{
struct btrfs_fs_info *info = (struct btrfs_fs_info *)congested_data;
int ret = 0;
- struct list_head *cur;
struct btrfs_device *device;
struct backing_dev_info *bdi;
#if 0
@@ -1144,8 +1143,7 @@ static int btrfs_congested_fn(void *congested_data, int
bdi_bits)
btrfs_congested_async(info, 0))
return 1;
#endif
- list_for_each(cur, &info->fs_devices->devices) {
- device = list_entry(cur, struct btrfs_device, dev_list);
+ list_for_each_entry(device, &info->fs_devices->devices, dev_list) {
if (!device->bdev)
continue;
bdi = blk_get_backing_dev_info(device->bdev);
@@ -1163,13 +1161,11 @@ static int btrfs_congested_fn(void *congested_data, int
bdi_bits)
*/
static void __unplug_io_fn(struct backing_dev_info *bdi, struct page *page)
{
- struct list_head *cur;
struct btrfs_device *device;
struct btrfs_fs_info *info;
info = (struct btrfs_fs_info *)bdi->unplug_io_data;
- list_for_each(cur, &info->fs_devices->devices) {
- device = list_entry(cur, struct btrfs_device, dev_list);
+ list_for_each_entry(device, &info->fs_devices->devices, dev_list) {
if (!device->bdev)
continue;
@@ -1995,7 +1991,6 @@ static int write_dev_supers(struct btrfs_device *device,
int write_all_supers(struct btrfs_root *root, int max_mirrors)
{
- struct list_head *cur;
struct list_head *head = &root->fs_info->fs_devices->devices;
struct btrfs_device *dev;
struct btrfs_super_block *sb;
@@ -2011,8 +2006,7 @@ int write_all_supers(struct btrfs_root *root, int
max_mirrors)
sb = &root->fs_info->super_for_commit;
dev_item = &sb->dev_item;
- list_for_each(cur, head) {
- dev = list_entry(cur, struct btrfs_device, dev_list);
+ list_for_each_entry(dev, head, dev_list) {
if (!dev->bdev) {
total_errors++;
continue;
@@ -2045,8 +2039,7 @@ int write_all_supers(struct btrfs_root *root, int
max_mirrors)
}
total_errors = 0;
- list_for_each(cur, head) {
- dev = list_entry(cur, struct btrfs_device, dev_list);
+ list_for_each_entry(dev, head, dev_list) {
if (!dev->bdev)
continue;
if (!dev->in_fs_metadata || !dev->writeable)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 293da65..c8815c1 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -326,10 +326,8 @@ static struct btrfs_space_info *__find_space_info(struct
btrfs_fs_info *info,
u64 flags)
{
struct list_head *head = &info->space_info;
- struct list_head *cur;
struct btrfs_space_info *found;
- list_for_each(cur, head) {
- found = list_entry(cur, struct btrfs_space_info, list);
+ list_for_each_entry(found, head, list) {
if (found->flags == flags)
return found;
}
@@ -3014,7 +3012,6 @@ loop_check:
static void dump_space_info(struct btrfs_space_info *info, u64 bytes)
{
struct btrfs_block_group_cache *cache;
- struct list_head *l;
printk(KERN_INFO "space_info has %llu free, is %sfull\n",
(unsigned long long)(info->total_bytes - info->bytes_used -
@@ -3022,8 +3019,7 @@ static void dump_space_info(struct btrfs_space_info
*info, u64 bytes)
(info->full) ? "" : "not ");
down_read(&info->groups_sem);
- list_for_each(l, &info->block_groups) {
- cache = list_entry(l, struct btrfs_block_group_cache, list);
+ list_for_each_entry(cache, &info->block_groups, list) {
spin_lock(&cache->lock);
printk(KERN_INFO "block group %llu has %llu bytes, %llu used "
"%llu pinned %llu reserved\n",
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 8adfe05..72c9277 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1324,12 +1324,11 @@ static noinline int add_pending_csums(struct
btrfs_trans_handle *trans,
struct inode *inode, u64 file_offset,
struct list_head *list)
{
- struct list_head *cur;
struct btrfs_ordered_sum *sum;
btrfs_set_trans_block_group(trans, inode);
- list_for_each(cur, list) {
- sum = list_entry(cur, struct btrfs_ordered_sum, list);
+
+ list_for_each_entry(sum, list, list) {
New ioctl API pushed out
Hello everyone, I had said that a revision of the ioctl API wouldn't be required and that I'd maintain compatibility even for my simple ioctl calls now. But, Ryusuke Konishi noticed that I didn't align the ioctl argument properly and that it was actually different sizes on 32 bit and 64 bit compiles. In general, the kernel has a compat ioctl facility to deal with this, letting us use different code to deal with a 32 bit executable run on 64 bit machines. But, it is a lot of cruft to carry around for a structure that is 1 byte off. I think it is better for the project if I just change the arg now and release v0.18 of btrfs-progs I've asked Linus to pull these ioctl changes, and so v2.6.29-rc2 will require v0.18 of btrfs-progs for the ioctl commands. The disk format has not changed. Any filesystems created by v0.17 and 2.6.29-rc1 will still be usable. The commands to scan devices, add, remove and balance volumes use these ioctls. You will need to update your btrfs-progs if you plan on using those commands in 2.6.29-rc2 Sorry for the trouble on this one, I really should have caught this simple error. -chris -- 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: [GIT PULL] adaptive spinning mutexes
Chris Mason wrote: On Thu, 2009-01-15 at 10:16 -0800, Linus Torvalds wrote: On Thu, 15 Jan 2009, Ingo Molnar wrote: btw., i think spin-mutexes have a design advantage here: in a lot of code areas it's quite difficult to use spinlocks - cannot allocate memory, cannot call any code that can sporadically block (but does not _normally_ block), etc. With mutexes those atomicity constraints go away - and the performance profile should now be quite close to that of spinlocks as well. Umm. Except if you wrote the code nicely and used spinlocks, you wouldn't hold the lock over all those unnecessary and complex operations. While this is true, there are examples of places we should expect speedups for this today. Concurrent file creation/deletion in a single dir will often find things hot in cache and not have to block anywhere (mail spools). And although not as common, NNTP servers using file per article storage. Concurrent O_DIRECT aio writes to the same file, where i_mutex is dropped early on. pipes should see a huge improvement. I'd like to see that. Didn't realize how slow pipes really are. I'll kick off some runs of my three benchmarks on ext3 for comparison. If there are things less synthetic people would like to see, please let me know. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- 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] (semi)revert compat.h to old version
Hi,
Without this patch btrfs doesn't compile on my system. I have Linux 2.6.27.8
on x86_64 compiled with gcc 4.1.2.
This is mostly the old compat.h with one typedef removed (typedef unsigned
__bitwise__ fmode_t;) as it was already defined on my system.
Happy hacking :)
Brcha
--
Filip Brčić
WWWeb: http://www.brcha.iz.rs
Jabber: br...@kdetalk.net
diff --git a/compat.h b/compat.h
index 7c4503e..204cda7 100644
--- a/compat.h
+++ b/compat.h
@@ -4,4 +4,29 @@
#define btrfs_drop_nlink(inode) drop_nlink(inode)
#define btrfs_inc_nlink(inode) inc_nlink(inode)
+#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 27)
+static inline struct dentry *d_obtain_alias(struct inode *inode)
+{
+ struct dentry *d;
+
+ if (!inode)
+ return NULL;
+ if (IS_ERR(inode))
+ return ERR_CAST(inode);
+
+ d = d_alloc_anon(inode);
+ if (!d)
+ iput(inode);
+ return d;
+}
+#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 28)
+# define __pagevec_lru_add_file __pagevec_lru_add
+# define open_bdev_exclusive open_bdev_excl
+# define close_bdev_exclusive(bdev, mode) close_bdev_excl(bdev)
+/* typedef unsigned __bitwise__ fmode_t; */
+#endif
+
+
#endif /* _COMPAT_H_ */
signature.asc
Description: This is a digitally signed message part.
btrfs and swap files on SSD's ?
Hi folks, Someone on the OpenMoko community list commented recently about having created a swap file on the SD card of their OpenMoko Neo phone and said that they'd been lazy as they'd not made a swap partition. My thought was that with an SSD aware filesystem like btrfs a swapfile would actually be a smarter move than a swap partition because it lets the filesystem try and even the wear generated by access to it which a swap partition will not have the freedom to do. To me that makes logical sense but given the complexity of the kernel and btrfs is it a fair comment to make and, also, would that be the case with btrfs at present ? cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
[PATCH] btrfsck: Exit and print error message when not able to open device
If btrfsck is not able to open a device, it segfaults. This fixes it and
prints an error message too.
---
btrfsck.c |3 +++
disk-io.c |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/btrfsck.c b/btrfsck.c
index 4a41e6d..cde0e68 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -2075,6 +2075,9 @@ int main(int ac, char **av)
radix_tree_init();
root = open_ctree(av[1], 0, 0);
+ if (root == NULL)
+ return 1;
+
ret = check_extents(root);
if (ret)
goto out;
diff --git a/disk-io.c b/disk-io.c
index c15cf53..e49c220 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -530,6 +530,7 @@ struct btrfs_root *open_ctree(const char *filename, u64
sb_bytenr, int writes)
fp = open(filename, flags, 0600);
if (fp < 0) {
+ fprintf (stderr, "Coult not open %s\n", filename);
return NULL;
}
root = open_ctree_fd(fp, filename, sb_bytenr, writes);
--
1.6.0.6
--
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
