linux-ext4 - Constant access (write) time.

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>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 06 Mar 2010 23:02:53 +0100
From:	Paul Chavent <paul.chavent@...c.net>
To:	linux-ext4@...r.kernel.org
Subject: Constant access (write) time.

Hello.

I'm writing a real-time application that have to stream pictures to a SSD.

The pictures are 640x480x1 pnm that are stored in one tar file. I have one picture every 100ms.

I decided to code a "write" thread that open a file on an ext4 filesystem created with :
# mke2fs -t ext4 -L DATA -O large_file,^has_journal,extent -v

It is mounted with :
# mount -t ext4 /dev/sda3 /var/data/

My file descriptor is open with these flags :
O_WRONLY | O_CREAT | O_TRUNC | O_SYNC | O_DIRECT

I use a noop io scheduler.

The problem is that the access (write) time (from a userspace point of view) is not constant. I join you a piece of code that reproduce the problem.

This leads me to ask the following questions : the solution to this problem is

(1) the kernel make such a job that the write time seems constant from a userspace point of view

(2) the userspace thread haven't a constant execution time but is bounded to a maximum

(3) the userspace thread have a constant execution time but use an other userspace thread by calling aio_write

In all case, the job (some block allocation i guess) have to be done. But i suppose that if it is done anticipatory by the kernel it can be preemted by realtime task and it is better.

In the third solution we can preempt the aio thread, but the allocation isn't anticipated.

So if you could give me your point of view...

Thank you for your advices.

Paul.

View attachment "main.c" of type "text/plain" (5166 bytes)