similar to: [PATCH V3 6/8] Cleancache: btrfs hooks for cleancache

> -----Original Message----- > From: Matt [mailto:jackdachef@gmail.com] > Sent: Tuesday, February 15, 2011 5:12 PM > To: Minchan Kim > Cc: Dan Magenheimer; gregkh@suse.de; Chris Mason; linux- > kernel@vger.kernel.org; linux-mm@kvack.org; ngupta@vflare.org; linux- > btrfs@vger.kernel.org; Josef Bacik; Dan Rosenberg; Yan Zheng; > miaox@cn.fujitsu.com; Li Zefan > Subject:

tmem is not supported on arm or arm64 yet. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 9e02d60..a18f350 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -145,7 +146,7 @@ config SWIOTLB_XEN config XEN_TMEM tristate - depends on !ARM + depends on !ARM && !ARM64 default m if

I have some Xen systems running Xen-4.1.1, dom0 linux-2.6.38 patched (it''s gentoo''s xen-sources) and domUs running linux-3.0.4 (vanilla sources from kernel.org). Block devices are phy on LVM2 volumes on DRBD-8.3.9 devices. Not immediately after boot, but after some I/O load on the disks I start seeing these in the domUs: blkfront: barrier: empty write xvdb1 op failed blkfront:

Hello! Recently I've migrated from samba 2.2.8a to 3.0.4. I use ldap as user database backend. To synchronize unix password the smbldap-passwd.pl script is used. But I need to sync virtual mail passwords as well. That is why I added to the script few lines of code. Mainly I call external programs. The code is like this: system("/etc/cron.hourly/sqwebmail-cron-cleancache"); When I

Dave Hall wrote: > THanks for the ideas. I haven't heard from anyone else yet, and hope that > someone on this list has done this before. I have tried multiple options > without any luck, and have a tough time understanding what else to try based > on the provided INSTALL documentation. > > Thanks > Dave > > >>-----Original Message-----

Hi gang, Here''s some trivial cleanups that I''ve built up while reading through the code. They''ve been run through xfstests -g quick. - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

While testing with my buffer read fio jobs[1], I find that btrfs does not perform well enough. Here is a scenario in fio jobs: We have 4 threads, "t1 t2 t3 t4", starting to buffer read a same file, and all of them will race on add_to_page_cache_lru(), and if one thread successfully puts its page into the page cache, it takes the responsibility to read the page''s data. And

XEN_DOM0 is a silent option that has been automatically selected when CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed to a menu configurable option then it would only give users the ability to compile out about 100 kbytes of code. As that option makes little sense to choose, and the option isn''t menu selectable anyway, then we can clean up some code by simply

XEN_DOM0 is a silent option that has been automatically selected when CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed to a menu configurable option then it would only give users the ability to compile out about 100 kbytes of code. As that option makes little sense to choose, and the option isn''t menu selectable anyway, then we can clean up some code by simply

XEN_DOM0 is a silent option that has been automatically selected when CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed to a menu configurable option then it would only give users the ability to compile out about 100 kbytes of code. As that option makes little sense to choose, and the option isn''t menu selectable anyway, then we can clean up some code by simply

While testing with my buffer read fio jobs[1], I find that btrfs does not perform well enough. Here is a scenario in fio jobs: We have 4 threads, "t1 t2 t3 t4", starting to buffer read a same file, and all of them will race on add_to_page_cache_lru(), and if one thread successfully puts its page into the page cache, it takes the responsibility to read the page''s data. And

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Hi, I have noticed that, in the code of linux/drivers/xen/balloon.c, there exists the snippet as this: static int __init balloon_init(void) { unsigned long pfn; struct page *page; if (!xen_pv_domain()) return -ENODEV; ..... } Does it means the driver will not work in HVM? If so, where is the HVN-enabled code for that? 2010-11-16 Rui Chu _______________________________________________

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 17 Feb 2011 13:20:20 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=29302 > > Summary: Null pointer dereference with large max_sectors_kb > Product: IO/Storage > Version: 2.5 > Kernel

Hi, The following series of patches implements in btrfs an ioctl to do out-of-band deduplication of file extents. To be clear, this means that the file system is mounted and running, but the dedupe is not done during file writes, but after the fact when some userspace software initiates a dedupe. The primary patch is loosely based off of one sent by Josef Bacik back in January, 2011.

Hey, It looks like one of the patches that went in Xen 4.1 blows up. This used to work over the weekend, so I can only surmise it is one the three patches. This is with a debug=y build (which has been working nicely for the last month or more). It looks like one of the patches that went in Xen 4.1 blows up. This used to work a day ago - that is c/s 23551 worked nicely. ----- Forwarded message

Hi, when mounting an intentionally corrupted btrfs filesystem i get the following warning and bug message. The image can be found here www.cccmz.de/~snakebyte/btrfs.2.img.bck.bz2 [ 297.406152] device fsid e14cf01de423381a-4bd40b603870018a <6>devid 2147483649 transid 9 /dev/loop0 [ 297.411937] ------------[ cut here ]------------ [ 297.412207] WARNING: at fs/btrfs/disk-io.c:805