[#3929] Can not generate a big file(more then 5MB)

Document created by Aaronwu Employee on Aug 28, 2013
Version 1Show Document
  • View in full screen mode

[#3929] Can not generate a big file(more then 5MB)

Submitted By: Vivi Li

Open Date

2008-02-22 04:15:00     Close Date

2008-03-17 18:50:21

Priority:

Medium     Assignee:

Sonic Zhang

Status:

Closed     Fixed In Release:

N/A

Found In Release:

N/A     Release:

Category:

N/A     Board:

N/A

Processor:

N/A     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

08r1

App binary format:

N/A     

Summary: Can not generate a big file(more then 5MB)

Details:

 

In 08r1 branch, can not generate a big file(more then 5MB) in BF548-EZKIT.

I use default configuration of BF548-EZKIT. It's ok with all other boards.

Here I use command:

dd if=/dev/zero of=/vv bs=1M count=16

It stops at this command.

 

Below is the log in BF548-EZKIT:

--

Linux version 2.6.22.18-ADI-2008R1-svn4329 (test@uclinux84-bf548-kernel) (gcc version 4.1.2 (ADI sv8

Hardware Trace Active and Enabled

Reset caused by Software reset

Blackfin support (C) 2004-2007 Analog Devices, Inc.

Compiled for ADSP-BF548 Rev 0.0

Blackfin Linux support by   blackfin.uclinux.org/

Processor Speed: 525 MHz core clock and 131 MHz System Clock

Board Memory: 64MB

Kernel Managed Memory: 64MB

Memory map:

  text      = 0x00001000-0x00175510

  rodata    = 0x00176000-0x001ed6d4

  data      = 0x001ee000-0x00204000

    stack   = 0x001ee000-0x001f0000

  init      = 0x00204000-0x005a0000

  bss       = 0x005a0000-0x005b15d0

  available = 0x005b15d0-0x03dff000

  DMA Zone  = 0x03e00000-0x04000000

Instruction Cache Enabled

Data Cache Enabled (write-through)

Built 1 zonelists.  Total pages: 15748

Kernel command line: root=/dev/mtdblock0 rw ip=10.100.4.50:10.100.4.174:10.100.4.174:255.255.255.0:f

Configuring Blackfin Priority Driven Interrupts

PID hash table entries: 256 (order: 8, 1024 bytes)

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory available: 57076k/65536k RAM, (3696k init code, 1489k kernel code, 640k data, 2048k dma, 584)

Blackfin Scratchpad data SRAM: 4 KB

Blackfin Data A SRAM: 16 KB (15 KB free)

Blackfin Data B SRAM: 16 KB (16 KB free)

Blackfin Instruction SRAM: 48 KB (42 KB free)

Security Framework v1.0.0 initialized

Mount-cache hash table entries: 512

NET: Registered protocol family 16

Blackfin GPIO Controller

Blackfin DMA Controller

ezkit_init(): registering device resources

SCSI subsystem initialized

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 2048 (order: 2, 16384 bytes)

TCP bind hash table entries: 2048 (order: 1, 8192 bytes)

TCP: Hash tables configured (established 2048 bind 2048)

TCP reno registered

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler cfq registered

bf54x-lq043: FrameBuffer initializing...

dma_alloc_init: dma_page @ 0x030e3000 - 512 pages at 0x03e00000

bfin-otp: initialized

bfin-wdt: initialized: timeout=20 sec (nowayout=0)

Serial: Blackfin serial driver

bfin-uart.1: ttyBF0 at MMIO 0xffc02000 (irq = 48) is a BFIN-UART

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

smsc911x: Driver version 2007-07-13.

register bfin atapi driver

scsi0 : pata-bf54x

ata1: PATA max UDMA/66 cmd 0x00000000 ctl 0xffc03800 bmdma 0x00000000 irq 68

ata1.00: ATA-6: TOSHIBA MK4032GAX, AD101A, max UDMA/100

ata1.00: 78140160 sectors, multi 16: LBA48

ata1.00: configured for UDMA/66

blk_queue_max_hw_segments: set to minimum 1

scsi 0:0:0:0: Direct-Access     ATA      TOSHIBA MK4032GA AD10 PQ: 0 ANSI: 5

sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB)

sd 0:0:0:0: [sda] Write Protect is off

sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB)

sd 0:0:0:0: [sda] Write Protect is off

sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sda: sda1 sda2

sd 0:0:0:0: [sda] Attached SCSI disk

physmap platform flash device: 00400000 at 20000000

physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank

NOR chip too large to fit in mapping. Attempting to cope...

Intel/Sharp Extended Query Table at 0x010A

Intel/Sharp Extended Query Table at 0x010A

Intel/Sharp Extended Query Table at 0x010A

Intel/Sharp Extended Query Table at 0x010A

Intel/Sharp Extended Query Table at 0x010A

Using buffer write method

Using auto-unlock on power-up/resume

cfi_cmdset_0001: Erase suspend on write enabled

Reducing visibility of 32768KiB chip to 4096KiB

RedBoot partition parsing not available

BF5xx on-chip NAND FLash Controller Driver, Version 1.2 (c) 2007 Analog Devices, Inc.

bf5xx-nand bf5xx-nand.0: page_size=256, data_width=8, wr_dly=3, rd_dly=3

NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)

Creating 2 MTD partitions on "NAND 256MiB 3,3V 8-bit":

0x00000000-0x00400000 : "Linux Kernel"

0x00400000-0x10000000 : "File System"

bfin-spi bfin-spi.0: Blackfin BF5xx on-chip SPI Contoller Driver, Version 1.0, regs_base@ffc00500, 4

bfin-spi bfin-spi.1: Blackfin BF5xx on-chip SPI Contoller Driver, Version 1.0, regs_base@ffc02300, 5

input: bf54x-keys as /class/input/input0

bf54x-keys: Blackfin BF54x Keypad registered IRQ 76

rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0

i2c /dev entries driver

i2c-bfin-twi i2c-bfin-twi.1: Blackfin BF5xx on-chip I2C TWI Contoller Driver, Version 1.8, regs_bas0

Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).

ASoC version 0.13.1

AD1980 SoC Audio Codec

asoc: AC97 <-> bf5xx-ac97 mapping ok

ALSA device list:

  #0: bf5xx-board (AD1980)

TCP cubic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

rtc-bfin rtc-bfin: setting the system clock to 2004-05-31 19:30:18 (1086031818)

eth0: SMSC911x/921x identified at 0x24000000, IRQ: 175

eth0: SMSC911x MAC Address: de:70:75:56:11:28

eth0: link down

IP-Config: Complete:

      device=eth0, addr=10.100.4.50, mask=255.255.255.0, gw=10.100.4.174,

     host=BF548, domain=, nis-domain=(none),

     bootserver=10.100.4.174, rootserver=10.100.4.174, rootpath=

Freeing unused kernel memory: 3696k freed

eth0: link up, 100Mbps, full-duplex, lpa 0x41E1

                           _____________________________________

        a8888b.           / Welcome to the uClinux distribution \

       d888888b.         /       _     _                         \

       8P"YP"Y88        /       | |   |_|            __  __ (TM)  |

       8|o||o|88  _____/        | |    _ ____  _   _ \ \/ /       |

       8'    .88       \        | |   | |  _ \| | | | \  /        |

       8`._.' Y8.       \       | |__ | | | | | |_| | /  \        |

      d/      `8b.       \      \____||_|_| |_|\____|/_/\_\       |

     dP   .    Y8b.       \   For embedded processors including   |

    d8:'  "  `::88b        \    the Analog Devices Blackfin      /

   d8"         'Y88b        \___________________________________/

  :8P    '      :888

   8a.   :     _a88P         For further information, check out:

._/"Yaa_:   .| 88P|            -   blackfin.uclinux.org/

\    YP"    `| 8P  `.          -   docs.blackfin.uclinux.org/

/     \.___.d|    .'           -   www.uclinux.org/

`--..__)8888P`._.'  jgs/a:f    -   www.analog.com/blackfin

 

Have a lot of fun...

 

 

BusyBox v1.4.1 (2008-02-22 16:53:51 CST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

 

root:/> mount

rootfs on / type rootfs (rw)

proc on /proc type proc (rw)

ramfs on /var type ramfs (rw)

sysfs on /sys type sysfs (rw)

devpts on /dev/pts type devpts (rw)

debugfs on /sys/kernel/debug type debugfs (rw)

securityfs on /sys/kernel/security type securityfs (rw)

root:/> free

              total         used         free       shared      buffers

  Mem:        60772        12752        48020            0            0

root:/> dd if=/dev/zero of=vv bs=1M count=16

--

 

 

I can telnet to the board and check the info there.

Here is the log:

--

test@uclinux84-bf548-kernel:~> telnet 10.100.4.50

Trying 10.100.4.50...

Connected to 10.100.4.50.

Escape character is '^]'.

 

 

BusyBox v1.4.1 (2008-02-22 16:53:51 CST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.

 

root:/> ps ax

  PID  Uid        VSZ Stat Command

    1 root        104 S   /init

    2 root            SW< [kthreadd]

    3 root            SWN [ksoftirqd/0]

    4 root            SW< [events/0]

    5 root            SW< [khelper]

   33 root            SW< [kblockd/0]

   34 root            SW< [ata/0]

   35 root            SW< [ata_aux]

   46 root            SW  [pdflush]

   47 root            DW  [pdflush]

   48 root            SW< [kswapd0]

   49 root            SW< [aio/0]

   50 root            SW< [cifsoplockd]

   51 root            SW< [cifsdnotifyd]

   85 root            SW< [scsi_eh_0]

   93 root            SW< [mtdblockd]

  109 root            SW< [bfin-spi.0]

  112 root            SW< [bfin-spi.1]

  149 root         40 S   inetd

  152 root        576 S   -/bin/sh

  153 root         32 S   /bin/watchdogd -f -s

  154 root        476 S   /sbin/syslogd -n

  155 root        476 S   /sbin/klogd -n

  157 root       1504 D   dd if=/dev/zero of=/vv bs=1M count=16

  158 root         56 S   /bin/telnetd

  159 root        576 S   sh

  160 root        480 R   ps ax

root:/> free

              total         used         free       shared      buffers

  Mem:        60772        20820        39952            0            0

root:/> ls -lh vv

-rw-r--r--    1 root     root         4.7M May 31 19:30 vv

root:/>

--

 

Follow-ups

 

--- Michael Hennerich                                        2008-02-22 07:03:02

Same issue as:

[#3850] rcp, ftpd, USB Mass storage not working

 

-Michael

 

--- Michael Hennerich                                        2008-02-22 10:58:33

Obviously the limit pagecache patch is causing this problem.

Introduced between svn rev. 2973:2974 

 

Sonic,

please assign to someone else.

 

-Michael

 

--- Michael Hennerich                                        2008-02-22 11:49:54

There was a follow up patch posted here:

  lkml.org/lkml/2007/1/17/96

Maybe this one works better

 

--- Sonic Zhang                                              2008-02-25 02:07:17

This bug is not against bf548 only. The default pagecache_ratio on bf548 is set

to 20%, while it is 100% on all other boards.

 

In this case, if you set pagecache_ratio to be less than 41%(about 23M of 55M

total memory) on bf537, following command blocks. This is because the VFS cache

pages asked by dd exceeds the limiation (23M).

 

dd if=/dev/zero of=/vv bs=1M count=16

 

This looks not a bug. It is just caused by the limitation of NOMMU arch.

 

 

--- Sonic Zhang                                              2008-02-25 02:11:14

A fixed cachepage_ratio value may not fit all kinds of application. How about

remove the default 20% in bf548 and ask user to set it when they want to run

fsck.ext2 and mplayer?

 

--- Mike Frysinger                                           2008-02-25 13:18:40

while that is worth looking into separately, pagecache limiting should not cause

indefinite blocking of any application.  if it does, then it's broken.

 

--- Michael Hennerich                                        2008-02-25 16:18:29

I’m pretty sure the limit pagecache support is not longer working correctly.

It prevents memory allocations to fail. It should just operate on file cache

pages.

See below how this should work.

 

As a side note – we’re not using this patch described below – we’re

using an initial try done by Aubrey and Roy.

Maybe we should implement Vaidyanathan approach.

 

 

  lkml.org/lkml/2007/1/17/96

 

"Hi Roy,

 

I have added a different pagecache reclaim logic around your

sysctl interface. This would ensure that only pagecache pages are

reclaimed if the limit is exceeded.

 

--Vaidy

 

Pagecache pages in memory can be limited to a percentage of total

RAM using this patch.

 

New sysctl entry /proc/sys/vm/pagecache_ratio has been added that

holds the total percentage of RAM that the user wants as pagecache. 

The default percentage is 90.

 

Depending on the work load, any percentage value can be set to derive

optimum overall performance. Minimum is 5 and max is 100.

 

balance_pagecache() routine is called on file backed access and the

current pagecache_limit is checked against utilisation.

 

If the limit is exceeded, then shrink_all_pagecache_memory() is

called that will walk the LRU list and remove unmapped pagecache

pages.  New scancontrol fields have been added to make decisions

in shrink_page_list() and shrink_active_list().

 

Pages counted under pagecache limit are file pages that are not mapped. 

Shared memory is mapped and not counted in the limit.

 

Test:

 

echo 40 > /proc/sys/vm/pagecache_ratio

(that is around 400MB on a 1GB RAM machine)

dd if=/dev/zero of=/tmp/foo bs=1M count=1024

 

cat /proc/meminfo

The "Cached: xxx" count should hit the set limit and not consume all

available memory.

 

Any feedback is appreciated."

 

--- Robin Getz                                               2008-02-25 23:41:48

Michael:

I don't think it is necessary to post this in every bug report?

 

Sonic:

I think this needs to get fixed. It is not just mplayer and fsck - but every

person/application who will soon be using large MMC & USB & PATA &

NAND file systems in real world systems. We enabled this - now we need to make

sure it is stable in all conditions. Right now, it is not.

 

-Robin

 

--- Robin Getz                                               2008-02-25 23:46:02

Sonic:

 

You wrote:

>This looks not a bug. It is just caused by the limitation of NOMMU arch.

 

This is a bug - if the page cache limit is hit - the VFS should write out to

the disk - and free something up - not hang. This is a bug of the page cache

limiting code - it looks like it was not updated to the latest kernel version

properly.

 

-Robin

 

--- Sonic Zhang                                              2008-02-26 04:27:40

Fixed.

 

--- Vivi Li                                                  2008-03-03 02:44:41

root:/> cat /proc/sys/vm/pagecache_ratio

20

root:/> cat /proc/meminfo

MemTotal:        60700 kB

MemFree:         47988 kB

Buffers:             0 kB

Cached:           7792 kB

SwapCached:          0 kB

Active:           1488 kB

Inactive:         6304 kB

SwapTotal:           0 kB

SwapFree:            0 kB

Dirty:               0 kB

Writeback:           0 kB

AnonPages:           0 kB

Mapped:              0 kB

Slab:             2220 kB

SReclaimable:     1428 kB

SUnreclaim:        792 kB

PageTables:          0 kB

NFS_Unstable:        0 kB

Bounce:              0 kB

CommitLimit:     30348 kB

Committed_AS:        0 kB

VmallocTotal:        0 kB

VmallocUsed:         0 kB

VmallocChunk:        0 kB

root:/> free

              total         used         free       shared      buffers

  Mem:        60700        12712        47988            0            0

root:/> time dd if=/dev/zero of=/5M.bin bs=1M count=5

dd: page allocation failure. order:0, mode:0xa00d2

Hardware Trace:

   0 Target : <0x00004740> { _dump_stack + 0x0 }

     Source : <0x0002cb52> { ___alloc_pages + 0x186 }

   1 Target : <0x0002cb52> { ___alloc_pages + 0x186 }

     Source : <0x0000ce12> { _printk + 0x16 }

   2 Target : <0x0000ce0e> { _printk + 0x12 }

     Source : <0x0000ccc4> { _vprintk + 0x1b8 }

   3 Target : <0x0000ccb8> { _vprintk + 0x1ac }

     Source : <0xffa00c82> { __common_int_entry + 0xca }

   4 Target : <0xffa00c20> { __common_int_entry + 0x68 }

     Source : <0xffa00a60> { _return_from_int + 0x58 }

   5 Target : <0xffa00a60> { _return_from_int + 0x58 }

     Source : <0xffa00a36> { _return_from_int + 0x2e }

   6 Target : <0xffa00a08> { _return_from_int + 0x0 }

     Source : <0xffa00c1c> { __common_int_entry + 0x64 }

   7 Target : <0xffa00c1a> { __common_int_entry + 0x62 }

     Source : <0xffa003a0> { _asm_do_IRQ + 0x68 }

   8 Target : <0xffa00398> { _asm_do_IRQ + 0x60 }

     Source : <0x00010f02> { __local_bh_enable + 0x3e }

   9 Target : <0x00010ec4> { __local_bh_enable + 0x0 }

     Source : <0x0001100c> { ___do_softirq + 0x94 }

  10 Target : <0x00011004> { ___do_softirq + 0x8c }

     Source : <0x00010fe4> { ___do_softirq + 0x6c }

  11 Target : <0x00010fd8> { ___do_softirq + 0x60 }

     Source : <0x00013de0> { _run_timer_softirq + 0x84 }

  12 Target : <0x00013d70> { _run_timer_softirq + 0x14 }

     Source : <0x0001ed54> { _hrtimer_run_queues + 0xc8 }

  13 Target : <0x0001ed24> { _hrtimer_run_queues + 0x98 }

     Source : <0x0001ed1a> { _hrtimer_run_queues + 0x8e }

  14 Target : <0x0001ed0c> { _hrtimer_run_queues + 0x80 }

     Source : <0x0001ed4a> { _hrtimer_run_queues + 0xbe }

  15 Target : <0x0001ed44> { _hrtimer_run_queues + 0xb8 }

     Source : <0x0001ed10> { _hrtimer_run_queues + 0x84 }

Stack from 0022dc58:

        00080000 0002cb56 002085f0 00080000 000a00d2 03d854cc 00000000

000a00d2

        0002ec68 002085ec 005e4aa0 000a00d2 00000000 00000000 000004b1

034b2004

        0002a11c 00673f14 00000000 00000000 000004b2 00000000 00001000

0004e000

        9aca0000 00000008 002085e8 00001000 00001000 00000001 00001000

03a719e0

        00189a94 00673e80 000b2000 00000100 00001000 0022de9c 0000000a

00000000

        005e4980 005e49a0 005e49c0 005e49e0 005e4a00 005e4a20 005e4a40

005e4a60

 

Call Trace:

[<0002a5ae>] ___generic_file_aio_write_nolock+0x1e2/0x3a0

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de5c>] _alloc_large_system_hash+0x110/0x2b4

[<0004e000>] ___writeback_single_inode+0xa4/0x2bc

[<000b2000>] _blk_queue_make_request+0x3c/0xb4

[<00032000>] _do_munmap+0x48/0x10c

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<0002a7c0>] _generic_file_aio_write+0x54/0xe4

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de9c>] _alloc_large_system_hash+0x150/0x2b4

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de9c>] _alloc_large_system_hash+0x150/0x2b4

[<0022de5c>] _alloc_large_system_hash+0x110/0x2b4

[<000c7d82>] _read_zero+0x2a/0x40

[<00036234>] _do_sync_write+0xac/0xe4

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<0022de14>] _alloc_large_system_hash+0xc8/0x2b4

[<0022de9c>] _alloc_large_system_hash+0x150/0x2b4

[<0001caf0>] _autoremove_wake_function+0x0/0x30

[<0022de54>] _alloc_large_system_hash+0x108/0x2b4

[<0022de54>] _alloc_large_system_hash+0x108/0x2b4

[<00001000>] _run_init_process+0x0/0x18

[<00032000>] _do_munmap+0x48/0x10c

[<00001000>] _run_init_process+0x0/0x18

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<000c7d86>] _read_zero+0x2e/0x40

[<00036aee>] _vfs_read+0xce/0xfc

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<000369a6>] _vfs_write+0x82/0xfc

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<0003502a>] _do_sys_open+0x92/0xac

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<00036e2a>] _sys_write+0x32/0x64

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<00035048>] _sys_open+0x0/0x24

[<0022def0>] _alloc_large_system_hash+0x1a4/0x2b4

[<00036df8>] _sys_write+0x0/0x64

[<00008000>] _bfin_demux_gpio_irq+0x54/0x94

[<00002000>] _get_sclk+0x4/0x58

[<0022e000>] ___free_pages_bootmem+0x0/0x34

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

[<00100000>] _cfi_intelext_unpoint+0x18/0xe0

 

Mem-info:

DMA per-cpu:

CPU    0: Hot: hi:   18, btch:   3 usd:   2   Cold: hi:    6, btch:   1 usd: 

0

Active:372 inactive:2768 dirty:0 writeback:0 unstable:0

free:10152 slab:558 mapped:0 pagetables:0 bounce:0

DMA free:40608kB min:1000kB low:1248kB high:1500kB active:1488kB

inactive:11072kB present:62992kB po

lowmem_reserve[]: 0 0

DMA: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 1*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB

1*4096kB 0*8192kB 2B

15871 pages of RAM

10185 free pages

696 reserved pages

10 pages shared

0 pages swap cached

...

root:/> free

              total         used         free       shared      buffers

  Mem:        60700        17536        43164            0            0

root:/> cat /proc/meminfo

MemTotal:        60700 kB

MemFree:         43164 kB

Buffers:             0 kB

Cached:          12600 kB

SwapCached:          0 kB

Active:           1492 kB

Inactive:        11108 kB

SwapTotal:           0 kB

SwapFree:            0 kB

Dirty:               0 kB

Writeback:           0 kB

AnonPages:           0 kB

Mapped:              0 kB

Slab:             2232 kB

SReclaimable:     1432 kB

SUnreclaim:        800 kB

PageTables:          0 kB

NFS_Unstable:        0 kB

Bounce:              0 kB

CommitLimit:     30348 kB

Committed_AS:        0 kB

VmallocTotal:        0 kB

VmallocUsed:         0 kB

VmallocChunk:        0 kB

root:/> ls -lh 5M.bin

-rw-r--r--    1 root     root         4.7M Jan 13 23:12 5M.bin

root:/>

 

--- Sonic Zhang                                              2008-03-12 05:13:28

Finally, I found this is not a real bug as described. Our default file system is

ram and VFS backed. All files are created in VFS cache. That means the value

pagecache_ratio controls the size of this file system. If we set it to 20%,  the

totol memory is 56M and initial FS size is 6M, the available space to create new

file is only 55M x 20% - 6M = 5M.

 

Anyway, there is improvement space in the pagecache limit patch to drop page

cache when the limit is met. But, this doesn't help to this bug. I added this

improvement in the kernel.

 

--- Robin Getz                                               2008-03-12 09:31:27

OK - that makes sense - when page cache is limited, and we fill initfs file

system, we get an error - but shouldn't we get "disk full" error - not

a OOM?

 

& I would also expect this not to occur on creating a nMeg file on

/dev/sda1?

 

-Robin

 

--- Yi Li                                                    2008-03-14 05:33:00

Documents/filesystem/ramfs-rootfs-initramfs.txt reads that:

 

ramfs is based on page cache/dentry cache. and "One downside of ramfs is

you can keep writing data into it until you fill up all memory, and the VM can't

free it because the VM thinks that files should get written to backing store

(rather than swap space), but ramfs hasn't got any backing store." And

tmpfs add size limit.

 

But I am not sure whether tmpfs can be used as initramfs.

 

 

--- Mike Frysinger                                           2008-03-17 18:50:21

using ramfs for / is fine ... dont fill it up

 

pagecache is no longer in the tree

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes