| To: | Ying-Hung Chen <ying@xxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: out of vmalloc space - use vmalloc<size> to increase size when mounting xfs FS |
| From: | Nathan Scott <nathans@xxxxxxx> |
| Date: | Mon, 5 Dec 2005 14:15:12 +1100 |
| Cc: | linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <4393A579.5090307@yingternet.com> |
| References: | <4392F5C5.5000706@yingternet.com> <20051205003014.GA1158@frodo> <4393A579.5090307@yingternet.com> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.3i |
On Mon, Dec 05, 2005 at 10:27:05AM +0800, Ying-Hung Chen wrote: > Hi Nathan, > > mount -t xfs /dev/hdb1 /Repository/01 > mount -t xfs /dev/hdc1 /Repository/02 > ... > > [root@localhost ~]# xfs_info /dev/hdb1 > meta-data=/usr/local/MatriVideo/bin/Repository/01 isize=256 > agcount=16, agsize=3052475 blks > = sectsz=512 > data = bsize=4096 blocks=48839600, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=23847, version=2 > = sectsz=512 sunit=0 blks Hmm, I don't understand that then - with these parameters, your incore log buffers are 32K, which will not cause any vmalloc calls, which was my first thought at a possible cause. I guess you could instrument the __vmalloc code in the kernel to printk the size parameter and do a dump_stack when its invoked, and see where all your vmalloc space is going... cheers. -- Nathan |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: out of vmalloc space - use vmalloc<size> to increase size when mounting xfs FS, Ying-Hung Chen |
|---|---|
| Next by Date: | Re: Filesystem Consistency Issues, Andi Kleen |
| Previous by Thread: | Re: out of vmalloc space - use vmalloc<size> to increase size when mounting xfs FS, Ying-Hung Chen |
| Next by Thread: | Filesystem Consistency Issues, Federico Sevilla III |
| Indexes: | [Date] [Thread] [Top] [All Lists] |