From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLh-DPrr2-ln for ; Thu, 30 Jan 2014 17:22:27 +0100 (CET) Received: from awesome.dsw2k3.info (unknown [IPv6:2a01:198:661:1f::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 30 Jan 2014 17:22:27 +0100 (CET) Date: Thu, 30 Jan 2014 17:22:20 +0100 From: Matthias Schniedermeyer Message-ID: <20140130162220.GA8697@citd.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] Filesystem unreadabe after resizing LUKS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pawel Chojnacki Cc: dm-crypt@saout.de On 30.01.2014 16:24, Pawel Chojnacki wrote: > Hello, > > Two days ago I tried to shrink my LUKS-encrypted /dev/sdb5 partition from > 119 to 110 GB according to > http://ubuntuforums.org/showthread.php?t=726724. Each step worked > properly, but in the end I'm not able to mount the > partition. I wanted to ask if you have any idea what may have caused that > and how to fix it: The actual commands you executed would be useful. > As far as I understand, the physical volume is 110 GB large, and filesystem > is 117.9 GB (why?). When trying to read from superblocks: A filesystem has the information stored about it's size stored inside itself, it doesn't needs (or uses) the information about the outer container-size for that. You have a problem when the outer size doesn't correspond with the stored filesystem size. Altough actually problematic is only the "filesystem is bigger" case, the other case is (potentially) just wasted space. As for shrinking, this is an operation that is NOT guruanteed to be successful. There maybe files in the space you want to shrink away and AFAIK there aren't any (OSS) tools that relocate files (except the XFS-specific xfs_fsr, but more about XFS in the next paragraph). The resize2fs-manpage isn't really informative. You would have to check the file-layouts of EVERY file. "filefrag" can tell you where the physical blocks of a file are located, you would need to calcutate the offset that will ouside the shrinked filesystem and move any file that is beyond the offset (Just copying such a file away and back MIGHT be enough, but that depends a little on luck) After that you would need to hope that there aren't any "other" things in "to be removed" space. Like for e.g. directory-data For e.g. i can definitly say that you can't shrink an XFS, because there simply isn't any tool that can do that. It's technically possible to do that, but nobodoy bothered to create the necessary tool which would check & relocate files/directores... and then fix up the metadata of the filesystem. There are people that ask the question from time to time. But "Backup & Restore" is still the only "officially supported" way to shrink a XFS filesystem. The only Linux filesystem (i know) that will definitly be able to "shrink" is BTRFS (Keyword: rebalancing), altough i'm unsure if it can do that today or at some point in the future. -- Matthias