| 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
| ||
|
Date: Mon, 28 Sep 2015 14:47:15 +0000 From: bugzilla-daemon@...zilla.kernel.org To: linux-ext4@...r.kernel.org Subject: [Bug 105121] lseek(SEEK_DATA) hangs for a long time for sparse files in the page cache https://bugzilla.kernel.org/show_bug.cgi?id=105121 --- Comment #1 from Theodore Tso <tytso@....edu> --- Thanks for reporting this! What's going on is that the "cat test > /dev/null" is instantiating 1GB of zero pages in the page cache. Currently, we are using the extent status to determine if a logical block is mapped to a physical block. However, the SEEK_DATA code dates back from a time when we were not storing the status of delayed allocation blocks in the extent status cache. So if the extent status cache indicates that the blocks are unwritten, the code which is handling fseek(SEEK_DATA) is scanning all of the pages to determine if any of the unwritten blocks happen to be modified in memory, but which haven't been pushed out to disk yet. We should be able to optimize this (and simplify the code as a bonus) by using the EXTENT_STATUS_DELAYED flag instead of trying to scan through all of the page structs (with all of the locking requirements this entails). Out of curiosity, what was the use case that caused you to notice this? -- You are receiving this mail because: You are watching the assignee of the bug. -- 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
Powered by blists - more mailing lists