linux-ext4 - Re: Heavy disk I/O on temporary mmap'ed files (ext4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 16 Feb 2011 09:40:52 -0600
From:	Javi <javier.cabezas@...il.com>
To:	Yongqiang Yang <xiaoqiangnk@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Heavy disk I/O on temporary mmap'ed files (ext4)

I suppose they are caused by the Ubuntu initialization scripts. If you
look at the timestamp, you can see that they are early in the boot
process.

Javi

On Wed, Feb 16, 2011 at 2:55 AM, Yongqiang Yang <xiaoqiangnk@...il.com> wrote:
>
>
> On Wed, Feb 16, 2011 at 4:33 PM, Javi <javier.cabezas@...il.com> wrote:
>>
>> I am using the current mount options:
>>
>> UUID=46fc675c-f196-4be2-bf4d-461d473de6b1 / ext4
>> errors=remount-ro,user_xattr 0 1
>>
>> And the dmesg messages I get are:
>>
>> [    2.908858] EXT4-fs (sda5): mounted filesystem with ordered data
>> mode. Opts: (null)
>> [   14.167465] EXT4-fs (sda5): re-mounted. Opts:
>> errors=remount-ro,user_xattr
>> [   15.512701] EXT4-fs (sda5): re-mounted. Opts:
>> errors=remount-ro,user_xattr,commit=0
>> [   20.801609] EXT4-fs (sda5): re-mounted. Opts:
>> errors=remount-ro,user_xattr,commit=0
>>
>> How can I give you more information?
>
> With dealloc enabled, temporary files with short life do not cause I/Os.
> It seems that somebody
> triggers something like a 'sync'.
>
> Why are there several remounts here, manual or not?
>
>>
>> Thanks,
>>  Javi
>>
>> On Wed, Feb 16, 2011 at 2:12 AM, Yongqiang Yang <xiaoqiangnk@...il.com>
>> wrote:
>> > Was ext4 mounted with dealloc?
>> >
>> > On Mon, Feb 7, 2011 at 3:41 PM, Javi <javier.cabezas@...il.com> wrote:
>> >>
>> >> I am developing a software based DSM. In order to avoid concurrent
>> >> updates on a memory page that is being updated by the runtime I am
>> >> using a shadow mapping to perform the updates. This mappings are
>> >> created by opening a file, unlinking it and mmap-ing on the file
>> >> descriptor. Everything is working but I am experiencing heavy disk I/O
>> >> during execution on a machine with a single ext4 file system. Other
>> >> machines that use ext3 partitions don't exhibit this behavior (there
>> >> is no disk I/O at all). This machine is using the kernel version
>> >> 2.6.35-25-generic.
>> >>
>> >> The exact steps performed to create the mappings are:
>> >>
>> >>    // Create the file
>> >>    snprintf(tmp, FILENAME_MAX, "/tmp/testXXXXXX");
>> >>    int fd = mkstemp(tmp);
>> >>    if(fd < 0) return NULL;
>> >>    unlink(tmp);
>> >>
>> >>    if(ftruncate(fd, count) < 0) {
>> >>        close(fd);
>> >>        return NULL;
>> >>    }
>> >>    ...
>> >>
>> >>    // Create a mapping
>> >>    addr = mmap(NULL, count, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
>> >>
>> >>
>> >> Does ext4 write to mmap'ed files although they don't have a name in
>> >> the file system? Am I doing anything wrong?
>> >>
>> >> Thanks,
>> >>  Javi
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-ext4"
>> >> in
>> >> the body of a message to majordomo@...r.kernel.org
>> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>> >
>> >
>> > --
>> > Best Wishes
>> > Yongqiang Yang
>> >
>> >
>>
>>
>>
>> --
>> Javi
>
>
>
> --
> Best Wishes
> Yongqiang Yang
>
>



-- 
Javi
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html