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?
Thanks,
Javi
On Wed, Feb 16, 2011 at 2:12 AM, Yongqiang Yang [off-list ref] wrote:
Was ext4 mounted with dealloc?
On Mon, Feb 7, 2011 at 3:41 PM, Javi [off-list ref] wrote:
quoted
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Wishes
Yongqiang Yang
--
Javi
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html