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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201003101544.o2AFimBW026206@demeter.kernel.org>
Date:	Wed, 10 Mar 2010 15:44:48 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 15420] EXT4_USE_FOR_EXT23 causes wrong free space calculation
 on ext2 and ext3

http://bugzilla.kernel.org/show_bug.cgi?id=15420





--- Comment #13 from Theodore Tso <tytso@....edu>  2010-03-10 15:44:46 ---
OK, I can confirm that the problem is with delayed allocation and indirect
files.   While downloading a 70 meg kernel source tar ball, the amount of space
shown as being used by df goes as high as 1 gigabyte (50% of the space on my
disk, about 25% of my available free memory) before dropping back down. as the
blocks get allocated.   Mounting with nodelalloc makes the problem go away.
Using extents, the df result will occasionally be as much as 1-2 megs but it is
much smaller in practice.

Using nodelalloc for ext2/3 mounts may make sense not just as a workaround, but
to help protect users using crappy desktop applications that don't know how to
use fsync().  (They'll still get screwed by btrfs, but the lazy application
writers and Phoronix they can complain to the btrfs developers about how they
are incompetent, and it's no longer my problem at that point.  :-)

We should try to improve the estimation logic for indirect blocks (I remember
being in a hurry to write the code to work around the regression caused by the
quota bugfix that has caused us so much heartache), but I don't think this is a
problem for people who are migrating from ext3 to ext4, since it's rare that
they will be extending an already existing indirect-mapped file.  The problem
with EXT4_USE_FOR_EXT23 is that they are _not_ migrating, and we're seeing a
weakness in delalloc with indirect block files; a weakness that was only
introduced recently, and one that I hope we can fix.   But for other reasons
mentioned above, we probably want to turn on nodelalloc anyway...

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ