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: Tue, 22 Sep 2009 17:31:06 +0200 From: jehan procaccia <jehan.procaccia@...sudparis.eu> To: Eric Sandeen <sandeen@...hat.com> CC: Theodore Tso <tytso@....edu>, linux-ext4@...r.kernel.org Subject: Re: howto downgrade ext4 to ext3 Eric Sandeen a écrit : > jehan procaccia wrote: >> Other inodes incriminated showed the same result -> over-quota . So >> if user data finally cannot be written, after all ... quota wouldn't >> allow it anyway . > > The unfortunate thing in your situation though is that the user > -thought- it did get written, just FYI. > > When quota is working properly, the denial is obvious up front. OK, indeed it's not fair for the users ! I had the time to experiment an ext4 FS mounted with -nodelalloc, and now quotas seems to work fine with it ;-) . here's a test on a FS mounted with -nodelalloc while writing with dd for an amount of data between interval soft 300M and hard 330M, it worked fine: [test@...-05 ~]$ dd if=/dev/zero of=./big-101M.dd bs=1024 count=101000 103424000 octets (103 MB) copiés, 9,06256 s, 11,4 MB/s $ quota -s test /dev/mapper/VolGroup03S2IA-LogVolS2ia01 317M* 293M 323M 7days 1760 0 0 Then, user "test" writes another 100 Mb and fails as expected : [test@...-05 ~]$ dd if=/dev/zero of=./big-102M.dd bs=1024 count=102000 dd: fermeture du fichier de sortie `./big-102M.dd': Débordement du quota d'espace disque $ quota -s test /dev/mapper/VolGroup03S2IA-LogVolS2ia01 323M* 293M 323M 6days 1761 0 0 [root@...eh /disk00/test/test] $ ll big* -rw-r--r-- 1 test mci 103424000 Sep 21 11:11 big-101M.dd -rw-r--r-- 1 test mci 35729408 Sep 21 11:13 big-102M.dd however in terms of performances, it seriously drops (nearly 50% !) with -nodelalloc on the NFS disk server, here's a simple local dd write test: ext4 -nodelalloc [root@...eh /disk00] $ dd if=/dev/zero of=./big-300M.dd bs=1024 count=300000 307200000 bytes (307 MB) copied, 1.20125 seconds, 256 MB/s ext4 -delalloc [root@...eh /disk01] $ dd if=/dev/zero of=./big-300M.dd bs=1024 count=300000 307200000 bytes (307 MB) copied, 0.752382 seconds, 408 MB/s however, the same test from an NFS workstation shows very small differences between partition mounted with nodelalloc and delalloc: -nodealloc + NFS $ dd if=/dev/zero of=./big-100M.dd bs=1024 count=100000 102400000 octets (102 MB) copiés, 9,09703 s, 11,3 MB/s delalloc + NFS $ dd if=/dev/zero of=./big-100M.dd bs=1024 count=100000 102400000 octets (102 MB) copiés, 9,00392 s, 11,4 MB/s I supose that NFS is the bottleneck ! I will announce a maintenance on that server in order to remount my 12 x 200GB partitions with -nodelalloc, if ever performances drops too much , then I'll probably choose to set quotas off until a redhat kernel package provides a solution . does 2.6.31 already patche to deal correclty with delalloc and quotas ? Thanks . -- 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