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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.7.1505010923400.29119@trent.utfs.org>
Date:	Fri, 1 May 2015 09:59:42 -0700 (PDT)
From:	Christian Kujau <lists@...dbynature.de>
To:	linux-ext4@...r.kernel.org
cc:	Theodore Ts'o <tytso@....edu>
Subject: Re: large directory entry

On Fri, 1 May 2015 at 10:31, Theodore Ts'o wrote:
> That's simply because shrinking directories while the file system is
> mounted is... tricky.  At some point we might try to get this
> supported, but until we do, there are two workarounds:
> 
> 1)  Recreate the directory, i.e.,

Yes, I did that and the copy is only 450 KB in size, so this works.

> 2) Run "e2fsck -fD /dev/sdXX" on the device containing /var while
> the file system is unmounted.

My /var is on the root disk and a normal fsck has been run during 
bootup just a few days ago, but without -D, of course.

> I'm not sure I would call this a bug; it's a long standing proper of
> ext2/3/4, the BSD FFS, etc., which is directories can't get shurnk by
> the file system.  At some point the directory had enough files in it
> that it grew to that size, and once having grown to that size, it
> won't shirnk on its own.

Yes, I noticed that with smaller sized directory, but somehow this 18 MB 
directory with "nothing" inside tipped me off.

> It would be possible to enhance ext4 to be able to shrink directories
> on-line, but it would require adding a new file system (to allow
> sparse directories), getting a new version of e2fsck, and then writing
> a bunch of new code, and it's just one of those things we've never
> gotten around to doing, mainly because for most use cases it rarely
> hits people, and the fix should be realtive well understood, as
> various Linux/Unix systems have suffered from this for decades.

Thanks for the explanation, Ted. I hope the next one asking this will find 
this in the archives, I somehow didn't :-\

Christian.
-- 
BOFH excuse #226:

A star wars satellite accidently blew up the WAN.
--
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