From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: No more space left on device issue Date: Mon, 19 Dec 2016 14:52:10 +0100 Message-ID: <877f6w58mt.fsf@gnu.org> References: <87vauhjbdn.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIyMU-0001rG-9v for guix-devel@gnu.org; Mon, 19 Dec 2016 08:52:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIyMR-00054H-3H for guix-devel@gnu.org; Mon, 19 Dec 2016 08:52:18 -0500 In-Reply-To: <87vauhjbdn.fsf@gmail.com> (Maxim Cournoyer's message of "Sun, 18 Dec 2016 11:16:52 -0800") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Maxim Cournoyer Cc: guix-devel@gnu.org Hi Maxim, Maxim Cournoyer skribis: > I've had this issue before but couldn't understand what was happening at > the time. At that time, I simply resized my filesystem then ran the > garbage collector. > > $ touch /tmp/test.txt > touch: cannot touch '/tmp/test.txt': No space left on device > > $ df -h > Filesystem Size Used Avail Use% Mounted on > none 1.9G 0 1.9G 0% /dev > /dev/sda1 37G 25G 11G 71% / > tmpfs 1.9G 0 1.9G 0% /dev/shm > cgroup 1.9G 0 1.9G 0% /sys/fs/cgroup > none 1.9G 12K 1.9G 1% /run/systemd > none 1.9G 0 1.9G 0% /run/user > tmpfs 376M 0 376M 0% /run/user/1000 > > In the #guix channel, jmd suggested that this might be an inode issue: > > $ sudo tune2fs -l /dev/sda1 > Password:=20 > tune2fs 1.42.13 (17-May-2015) > Filesystem volume name: my-root > Last mounted on: / > Filesystem UUID: 2b2b35a6-8f47-4fc2-9700-bda7fc1044cd > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index fil= etype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file= dir_nlink extra_isize > Filesystem flags: signed_directory_hash=20 > Default mount options: user_xattr acl > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 2445984 > Block count: 9764864 > Reserved block count: 488242 > Free blocks: 3183059 > Free inodes: 23 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Group descriptor size: 64 > Reserved GDT blocks: 1024 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 8208 > Inode blocks per group: 513 > Flex block group size: 16 > Filesystem created: Tue Nov 1 08:38:50 2016 > Last mount time: Sun Dec 18 10:47:37 2016 > Last write time: Sun Dec 18 10:47:37 2016 > Mount count: 20 > Maximum mount count: -1 > Last checked: Tue Nov 1 08:38:50 2016 > Check interval: 0 () > Lifetime writes: 146 GB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 32 > Desired extra isize: 32 > Journal inode: 8 > Default directory hash: half_md4 > Directory Hash Seed: 330c34f4-9c29-4b59-bb21-d8d00770e2e7 > Journal backup: inode blocks > > > It does seem like it is; the "Free inodes" count is very low at 23 and > this is only refreshed at the time the filesystem is mounted (since I > last booted). Indeed, it=E2=80=99s low on free inodes. :-) That said, 37=C2=A0G is not that much (my laptop=E2=80=99s root partition, = which includes the store, is 64=C2=A0G, and I expect most users are in this ballpark). So I wonder if there might be something else consuming inodes on this file system. Any ideas? My root partition has different settings though (it=E2=80=99s really ext3): --8<---------------cut here---------------start------------->8--- $ sudo tune2fs -l /dev/sda2 tune2fs 1.42.13 (17-May-2015) Filesystem volume name: root Last mounted on: / Filesystem UUID: c5307e6b-d1ba-499d-89c5-cb0b143577c4 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filet= ype needs_recovery sparse_super large_file --8<---------------cut here---------------end--------------->8--- Could it be that one of these explains the difference? FWIW mirror.hydra.gnu.org and hydra.gnu.org both have a 1.5TB /gnu as ext4. In the past we had issues where the directory index of /gnu/store/.links (used for deduplication) would be full (that=E2=80=99s really the directory index, not a lack of inodes), which was fixed in 12b6c951cf5ca6055a22a2eec85665353f5510e5. Ludo=E2=80=99.