From owner-freebsd-fs@FreeBSD.ORG Sun Sep 22 22:43:28 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E96EDB3D; Sun, 22 Sep 2013 22:43:27 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 56D072BC5; Sun, 22 Sep 2013 22:43:27 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id e52so1335423eek.2 for ; Sun, 22 Sep 2013 15:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=faxSyFTHcfBmWLL3As2LoxHQbjZozqBsAx5FF74onu8=; b=Fs3f3HP9TYqm8BxVadjm7Gd027ACmn5mImjtvRLEqdPWbDVyE3tJXxSdt82DRkyMxD ILwn41DZWBHqrSywLqbeXBdp4R9UWgGvHxBRnYuvEm5IWVQuv2q9fayBdNIQg7Kb2PO6 yguXHjcqvcvGg8nBOtBbMY8RdRU4O6XZV6hjbF+TO9TLGI3X5cJXAPpFZ+P3fCgTccJf R8sr/kQxkyee3xbn6egiEi/htT4PYS83r4W1lnL9gOlmuMLjxI1HlaNUY+uCuWClVjfZ 1MHiCl+cze96b0p2r6Z/eNDBQQZQXdcVCbY/3YS4boEq9jYjp1pkx6VXN3PhKltnLrJc DLRg== X-Received: by 10.14.172.133 with SMTP id t5mr31323110eel.35.1379889804963; Sun, 22 Sep 2013 15:43:24 -0700 (PDT) Received: from [192.168.1.102] (addn239.neoplus.adsl.tpnet.pl. [79.184.65.239]) by mx.google.com with ESMTPSA id bn13sm37271036eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 15:43:24 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= X-Priority: 3 (Normal) In-Reply-To: <724152380.20130921144811@serebryakov.spb.ru> Date: Mon, 23 Sep 2013 00:43:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0AA0A9CE-C692-4183-94FA-BC43837ADAE3@FreeBSD.org> References: <724152380.20130921144811@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.1510) Cc: freebsd-fs , Kirk McKusick X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 22:43:28 -0000 Wiadomo=B6=E6 napisana przez Lev Serebryakov w dniu 21 = wrz 2013, o godz. 12:48: > Hello, freebsd-fs. >=20 > My server paniced tonight with UFS problem: >=20 > ufs/root[WRITE(offset=3D385499136, length=3D16384)]error =3D 22 > g_vfs_done():ufs/root[WRITE(offset=3D385564672, length=3D16384)]error = =3D 22 > g_vfs_done():ufs/root[WRITE(offset=3D385712128, length=3D16384)]error = =3D 22 > g_vfs_done():ufs/root[WRITE(offset=3D385826816, length=3D16384)]error = =3D 22 > g_vfs_done():ufs/root[WRITE(offset=3D770703360, length=3D16384)]error = =3D 22 > g_vfs_done():ufs/root[WRITE(offset=3D770719744, length=3D16384)]error = =3D 22 > g_vfs_done():ufs/var[WRITE(offset=3D268539904, length=3D2048)]error =3D = 22 > /var: got error 22 while accessing filesystem > panic: softdep_deallocate_dependencies: unrecovered I/O error > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff8047a836 at kdb_backtrace+0x66 > #1 0xffffffff8044382e at panic+0x1ce > #2 0xffffffff8059c040 at clear_remove+0 > #3 0xffffffff804bf835 at brelse+0x75 > #4 0xffffffff804c2258 at bufdone+0x68 > #5 0xffffffff804bcb0e at biodone+0xae > #6 0xffffffff803e289c at g_io_schedule_up+0xac > #7 0xffffffff803e2ffc at g_up_procbody+0x5c > #8 0xffffffff804144ef at fork_exit+0x11f > #9 0xffffffff805f53de at fork_trampoline+0xe >=20 > and "fsck_ffs" refused to fix two OTHER (/usr and /tmp) SU+J-enabled = FFSes with same messages: >=20 > Journal file sequence mismatch XXX !=3D YYY > UNEXPECTED SU+J INCONSISTENCY > INTERNAL ERROR: GOT TO reply() > UNIXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY >=20 > and exited with signal 11. >=20 > So, here are two questions: >=20 > (1) What does "error 22" mean? Disk doesn't show ANY errors in = S.M.A.R.T. > (and all internal tests are Ok). Also, here are NO ANY driver (AHCI) = errors > in post-mortem dump. It doesn't look like hardware problem. According to "man errno", 22 is EINVAL. Which is... weird, to say the = least. What's below the filesystem? I mean, what's the GEOM tree? > (2) How to avoid fsck refuses in such situations? Why OTHER (not ones = with > write errors) FSes get errors? It looks like one another problem with = SU+J. Try to make fsck _not_ use journal. Simply respond "n" when it asks if = you want it to use journal. > Please note, these FSes reside directly on SATA drive, without any = software or > hardware RAIDs. No labels, for example? [..] From owner-freebsd-fs@FreeBSD.ORG Sun Sep 22 23:19:20 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 793E7C9D for ; Sun, 22 Sep 2013 23:19:20 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 514ED2DCD for ; Sun, 22 Sep 2013 23:19:20 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id q10so2507679pdj.34 for ; Sun, 22 Sep 2013 16:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=KOlJcYFDt5bmfqJCWdtQ6bg6mNU7uKz6JomOZSNqY4M=; b=FMTQmnkDhOUvYbkyquCfnFABYi0I8+QiNfq44PnHzKeY/6lG0IANuXxNhE/Pd9oOUn 6yYuo6xvoJIqWlxBW48hYXQFIQM829Eg5N6mvi3LazzXAMogxQOW5XgG0H8pBgqCSmlv KAaT67cPMiRmZfg2TzI9P9027eSLWDmPp2+fE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=KOlJcYFDt5bmfqJCWdtQ6bg6mNU7uKz6JomOZSNqY4M=; b=c+uGrSLU8Ny9b9Dd+ZkLq5K5Zckw6h8a8/uql4eC8623/yl3m1s+Ddhp3E7zB0aRp1 /jeAh9ioo7EWdyZY2+qJlbyHVYlqcJDPZtvIW2Ej+HSUOhvyZ+i3jmKRIceVhrX/EmFw 0ZR8K/VEbfpz3vHZa2tdrdjmitxWoD1FZpkIQY0tAHgHwJ3RLKi2nuQJZuZ+fIge3YEo 20vDCYSympOk+DKmK5wHCPkMmi+9rWgH8J1C8WjuWPzcGvpGhbKkowRN8qBeYi8MJHRt RhStCz0KOaNhe/txEJgFWzkQhjPcyulGWXKyX7WxeUcdKdn57E4p+jDJGhxzDKCfDl/H 83Gw== X-Gm-Message-State: ALoCoQlFRhrNpwUMWOj5yWbklB8qX2Np6tkx4Yhi93TKAh+CeqRlBzUrVgrPEfSGPZTlW9KcfgmM MIME-Version: 1.0 X-Received: by 10.68.212.37 with SMTP id nh5mr20906809pbc.16.1379891959829; Sun, 22 Sep 2013 16:19:19 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Sun, 22 Sep 2013 16:19:19 -0700 (PDT) Date: Sun, 22 Sep 2013 16:19:19 -0700 Message-ID: Subject: OpenZFS at EuroBSDcon From: Matthew Ahrens To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 23:19:20 -0000 FYI: Martin Matuska and I will be speaking about OpenZFS at EuroBSDcon this Saturday, September 18th at 2:30pm. We'll be talking about new and upcoming features in ZFS on FreeBSD, as well as OpenZFS and the development models on various platforms. More info: http://2013.eurobsdcon.org/eurobsdcon-2013/talks/#AhrensMatuska List of upcoming OpenZFS talks: http://www.open-zfs.org/wiki/Events --matt p.s. I ran out of OpenZFS T-shirts at BSDCAN... is it possible there was a reprint? Only one way to find out: come to our talk and regale us with tales of your largest, fastest, or most outrageous ZFS installations. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 01:23:19 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 307C3AE1 for ; Mon, 23 Sep 2013 01:23:19 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06A6723F2 for ; Mon, 23 Sep 2013 01:23:18 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz1so1641536pad.2 for ; Sun, 22 Sep 2013 18:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=auDCZ7ExZBTX1HnDZRLNLPkJs0Cjrl/mcoBGcf/oNGw=; b=A67oPlsYp4sfTIiUcYsud+SYAUv85xGfJToNQmNw9tQII5kwz6e+3XTwm0NJP5VMWw gJ8Y+IR1bdsTLkokzw/cT0sOd5vAt0h8Ajn/OKDtZMvQEQV6oTqj7u86Oa+ra9yiDZDL ep0sEgqBAT8lwy+jqaP0elNjdFjfmxvdcw6Lk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=auDCZ7ExZBTX1HnDZRLNLPkJs0Cjrl/mcoBGcf/oNGw=; b=GvTXGDe2BF5DnBBDl1PTfVEW3qL5AsSWil8RT0KADUDmyNnJSUEz0PRjXxz2Pr206a Ve2LMdO4Gky37cRIC0BRtfyL1/Y/rGpU/I8aHXliYeBy3NTqWvxAptTGp3LTIATgCbwf byq1RS8iO0cHOvaKW9R73qqKeap+1pHaAeqYNnKy89JFZEG360oDw40YABY/zOcnH+HS oTiMjNosV5a5DAvHTAJlgRzQ+hYp1J3TfXFmWo6IPlmopDza06+ceKfZ+9EQIT624Kc3 yxOok5ehFOu0RTwc4COdKublpiF5/up06ESdBcy2BkwumhaZt4+47Go8yxb0MJcaRGfh Kesg== X-Gm-Message-State: ALoCoQk7Ofd2KmR3GwslZPAnjJmqTgdKNbpp9WSk3ZH8B+GpzqsE/8eQ5+REK/Ia81m4shidmdGW MIME-Version: 1.0 X-Received: by 10.66.249.231 with SMTP id yx7mr5435907pac.116.1379899397948; Sun, 22 Sep 2013 18:23:17 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Sun, 22 Sep 2013 18:23:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Sep 2013 18:23:17 -0700 Message-ID: Subject: Re: OpenZFS at EuroBSDcon From: Matthew Ahrens To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 01:23:19 -0000 On Sun, Sep 22, 2013 at 4:19 PM, Matthew Ahrens wrote: > FYI: Martin Matuska and I will be speaking about OpenZFS at EuroBSDcon > this Saturday, September 18th at 2:30pm. > Whoops, that should read September 28th. --matt From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 11:06:44 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 98E93BF3 for ; Mon, 23 Sep 2013 11:06:44 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 270A9212D for ; Mon, 23 Sep 2013 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8NB6hNJ069433 for ; Mon, 23 Sep 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8NB6hP5069431 for freebsd-fs@FreeBSD.org; Mon, 23 Sep 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Sep 2013 11:06:43 GMT Message-Id: <201309231106.r8NB6hP5069431@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:06:44 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/181966 fs [zfs] Kernel panic in ZFS I/O: solaris assert: BP_EQUA o kern/181834 fs [nfs] amd mounting NFS directories can drive a dead-lo o kern/181565 fs [swap] Problem with vnode-backed swap space. o kern/181377 fs [zfs] zfs recv causes an inconsistant pool o kern/181281 fs [msdosfs] stack trace after successfull 'umount /mnt' o kern/181082 fs [fuse] [ntfs] Write to mounted NTFS filesystem using F o kern/180979 fs [netsmb][patch]: Fix large files handling o kern/180876 fs [zfs] [hast] ZFS with trim,bio_flush or bio_delete loc o kern/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS o kern/178713 fs [nfs] [patch] Correct WebNFS support in NFS server and s kern/178467 fs [zfs] [request] Optimized Checksum Code for ZFS o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178387 fs [zfs] [patch] sparse files performance improvements o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/178103 fs [kernel] [nfs] [patch] Correct support of index files o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/145750 fs [unionfs] [hang] unionfs locks the machine s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/67326 fs [msdosfs] crash after attempt to mount write protected o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t o kern/9619 fs [nfs] Restarting mountd kills existing mounts 337 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 12:18:22 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 678B3A6C; Mon, 23 Sep 2013 12:18:22 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 26B4C27DF; Mon, 23 Sep 2013 12:18:21 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5b:71c5:b3bc:c366]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id CBF6B4AC59; Mon, 23 Sep 2013 16:18:14 +0400 (MSK) Date: Mon, 23 Sep 2013 16:18:10 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1064796147.20130923161810@serebryakov.spb.ru> To: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-Reply-To: <0AA0A9CE-C692-4183-94FA-BC43837ADAE3@FreeBSD.org> References: <724152380.20130921144811@serebryakov.spb.ru> <0AA0A9CE-C692-4183-94FA-BC43837ADAE3@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs , Kirk McKusick X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:18:22 -0000 Hello, Edward. You wrote 23 =F1=E5=ED=F2=FF=E1=F0=FF 2013 =E3., 2:43:23: ETN> According to "man errno", 22 is EINVAL. Which is... weird, to say the= least. ETN> What's below the filesystem? I mean, what's the GEOM tree? It is typical for old-skool installation, with addition of UFS labels: ada0 -MBR-> ada0s1 -BSD LABEL-> ada0s1[abdef]. Moutns are via UFS labels (not glabel!) ufs/root =3D=3D ada0s1a ufs/var =3D=3D ada0s1d ufs/tmp =3D=3D ada0s1e ufs/usr =3D=3D ada0s1f /dev/ufs/root on / (ufs, local, soft-updates) /dev/ufs/tmp on /tmp (ufs, local, journaled soft-updates) /dev/ufs/usr on /usr (ufs, NFS exported, local, journaled soft-updates) /dev/ufs/var on /var (ufs, local, journaled soft-updates) Swap is configured via glabel label/swap =3D=3D ada0s1b >> (2) How to avoid fsck refuses in such situations? Why OTHER (not ones wi= th >> write errors) FSes get errors? It looks like one another problem with SU= +J. ETN> Try to make fsck _not_ use journal. Simply respond "n" when it asks i= f you want ETN> it to use journal. /usr and /tmp were fixed by _not_ using journal, when I see that server g= oes to single-user mode. /var and / were fixed before that by fsck runs on boot sequence after this panic, so I leave them as-is, because, I didn't know about write errors at this moment... >> Please note, these FSes reside directly on SATA drive, without any softw= are or >> hardware RAIDs. ETN> No labels, for example? See above. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 12:21:12 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A328FB9C for ; Mon, 23 Sep 2013 12:21:12 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 638302832 for ; Mon, 23 Sep 2013 12:21:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5b:71c5:b3bc:c366]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id F30654AC58 for ; Mon, 23 Sep 2013 16:21:10 +0400 (MSK) Date: Mon, 23 Sep 2013 16:21:06 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <131058847.20130923162106@serebryakov.spb.ru> To: freebsd-fs Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-Reply-To: <201309222224.r8MMO2o7025466@chez.mckusick.com> References: <724152380.20130921144811@serebryakov.spb.ru> <201309222224.r8MMO2o7025466@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:21:12 -0000 Hello, Kirk. You wrote 23 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= 2:24:02: [SEND THIS NOT ONLY DIRECTLY, BUT IN LIST TOO] >> I have dumped both FSes with "dumpfs" and "dumpfs -f" before manual che= ck >> and have block-dumped /tmp (as it is small enough). >>=20 >> You could find them at >>=20 >> http://lev.serebryakov.spb.ru/FreeBSD/suj-crash/ >>=20 >> --=20 >> // Black Lion AKA Lev Serebryakov KM> Have you run a manual (fsck -f) on the affected filesystems? If so, Hm. What do you mean by "Affected" here? I have 4 filesystems (/, /var, /tmp, /usr), 2 of them was affected before crash (/ and /var -- WRITE errors), but these were fixed by fsck automatically. And two of them (/tmp and /usr) were not affected before crash, but fsck refused to fix them automatically. I've run fsck -f /tmp and /usr, but not on / and /var, as I didn't see dmesg buffer when system was in single-user mode (I didn't know about WRITE errors yet) and I trust fsck, which says, that it repair them successfully with journal on boot after crash. And, yes, /tmp and /var were fixed with several questions like "invalid block count, fix or not". I didn't save output :( KM> was it able to clean them up? If not, please do so and save the output KM> of fsck (using script command is usually the easiest way to do this). It looks like I need to run manual fsck on / and /var (which are mentioned as WRITE ERROR in post-mortem dump), but I need to get physical access to this server, and it is hard for next two weeks :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 13:15:25 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 591FBEB; Mon, 23 Sep 2013 13:15:25 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2ED472BB2; Mon, 23 Sep 2013 13:15:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8NDFPZ5002768; Mon, 23 Sep 2013 13:15:25 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8NDFO3d002764; Mon, 23 Sep 2013 13:15:24 GMT (envelope-from gavin) Date: Mon, 23 Sep 2013 13:15:24 GMT Message-Id: <201309231315.r8NDFO3d002764@freefall.freebsd.org> To: simon@comsys.ntu-kpi.kiev.ua, gavin@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Subject: Re: kern/178713: [nfs] [patch] Correct WebNFS support in NFS server and client from sys/fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:15:25 -0000 Synopsis: [nfs] [patch] Correct WebNFS support in NFS server and client from sys/fs State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Mon Sep 23 13:12:49 UTC 2013 State-Changed-Why: Submitter requested that this PR be closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=178713 From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 13:21:07 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C4BB77C1; Mon, 23 Sep 2013 13:21:07 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9AF012C4F; Mon, 23 Sep 2013 13:21:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8NDL7rO004666; Mon, 23 Sep 2013 13:21:07 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8NDL7H6004665; Mon, 23 Sep 2013 13:21:07 GMT (envelope-from gavin) Date: Mon, 23 Sep 2013 13:21:07 GMT Message-Id: <201309231321.r8NDL7H6004665@freefall.freebsd.org> To: simon@comsys.ntu-kpi.kiev.ua, gavin@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Subject: Re: kern/178103: [kernel] [nfs] [patch] Correct support of index files for WebNFS exports X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:21:07 -0000 Synopsis: [kernel] [nfs] [patch] Correct support of index files for WebNFS exports State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Mon Sep 23 13:16:49 UTC 2013 State-Changed-Why: PR closed at submitters request. http://www.freebsd.org/cgi/query-pr.cgi?pr=178103 From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 13:34:07 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EB0EAE57; Mon, 23 Sep 2013 13:34:07 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C2F142D29; Mon, 23 Sep 2013 13:34:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8NDY7Si006754; Mon, 23 Sep 2013 13:34:07 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8NDY71j006753; Mon, 23 Sep 2013 13:34:07 GMT (envelope-from gavin) Date: Mon, 23 Sep 2013 13:34:07 GMT Message-Id: <201309231334.r8NDY71j006753@freefall.freebsd.org> To: simon@comsys.ntu-kpi.kiev.ua, gavin@FreeBSD.org, freebsd-fs@FreeBSD.org From: gavin@FreeBSD.org Subject: Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly atomic updates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:34:08 -0000 Synopsis: [nfs] [patch] NFS exports atomic and on-the-fly atomic updates State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Mon Sep 23 13:32:13 UTC 2013 State-Changed-Why: Closed at request of submitter. http://www.freebsd.org/cgi/query-pr.cgi?pr=136865 From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 15:59:05 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 64FF16F for ; Mon, 23 Sep 2013 15:59:05 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF35026C5 for ; Mon, 23 Sep 2013 15:59:04 +0000 (UTC) Received: from [66.196.81.173] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 15:59:03 -0000 Received: from [98.139.211.202] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 15:59:03 -0000 Received: from [127.0.0.1] by smtp211.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 15:59:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379951943; bh=tMexr3togx4951KiLecbXVR+X8y17blMblTPevH7AsM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=IGkosppqDuuq4UVNqRzHPKmpl8T0oMD/IgaOSZJc3aQ9bsMelfViHOdQrs7vMZvNO4apJRYmwdGjdWHxbNCiyisqURS+hMRA9yk2ftCcuVGMBffDOeAbwaswJlaTZb1Kx1tuROwUgvol4lM6EWloWSOKR6aQ3RH+aP1Gv5xdiIk= X-Yahoo-Newman-Id: 331044.70307.bm@smtp211.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZMv3LFgVM1mnEzGvqP1w6AhDh7MkgXSRsUpWfc7F1ZRpsCw 6XSgoiZyJkQOXfE4mZA0M5.3mG9VcdS6JfCvB5zwcfMY77Tog7cDu_D01UDS L8f9WiCQzzNQqKvUjs6b2V6GjPqQmCS97TypHyHjU7pQb5uIR4JDvU9fpg9p Kqsm_q3habHbZ4VqLrMXImxLMr2PTiBwtqxGIp9lD1kcgWXYJUtWjE8m.lMW UhKMdBmEY2zksnuDVIuDI2m7EjCj7xhk89IInCE6ihLrdhHR9dJXgpUHllc_ cFKeNT0l4UlOgkXMYYIiirv5J220AG7WI_DpZk8TjF3O2Rh2Ekn4XT__08gN QCOoycsP6jLb5vjR7RlvqmpYeVmRUG0KT_W3F5wGwidkWTRW3I07B.hIiNrK B9oS0orfiDeAhLisxaYXatCBxCTiMccNj363cSWgCSu27Y0iRtyD0H1SceGp 3ho5j.BjTYBFCvSpaGpD7M99lP2Jl2x2W1cyC0dfZJQ08n6uuIXbFsXH0OYZ YEsUSujAoPMU3Hdq0xdmzw9yGXGM9rbPoviq6xTcBpZbxa6PYK6VInrUkodG xEg-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp211.mail.bf1.yahoo.com with SMTP; 23 Sep 2013 08:59:03 -0700 PDT Subject: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN From: Sean Bruno To: freebsd-fs Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-qY0k3IygIQKXYmuQRk/D" Date: Mon, 23 Sep 2013 08:59:01 -0700 Message-ID: <1379951941.1612.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:59:05 -0000 --=-qY0k3IygIQKXYmuQRk/D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, I'm confused by this check: if (fstypelen >=3D MFSNAMELEN - 1 || fspathlen >=3D MNAMELEN - 1) { error =3D ENAMETOOLONG; goto bail; } MFSNAMELEN is 16, why do we check against >=3D MFSNAMELEN - 1? Why dont we check against (> MFSNAMELEN - 1) or (>=3D MFSNAMELEN)? Is a 14 character fstypelen with a "\0" at the end considered too long? Sean p.s. e.g. mount -t fuse.glusterfs ... --=-qY0k3IygIQKXYmuQRk/D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSQGU+AAoJEBkJRdwI6BaHOAUH/09VhiTVOo2XKSaiFWlju+eZ eM/s6X6WtfqHpoLa6Zg5v5DULcVj1GT6y/OEeudt6rG9u8qHODEB7vXaTJ8Jik6Z rBnq7MHu7PGGIV8GoV4U3fVNLBZ2B1KLcqYNQflxWGLlpvgv6F30VwszuEbhfsfy UEjCRjMEZpsKsCswU5s8gMHliZjreai8B6QGVGcrUD6TuqshwrPKERKrZueeLxig //f0Oc/sdKXMo3+FIbe8x5zB9ufZZpUIsRpfS6RrBa8iAa10e0075fWFybbjWsEf rJVAYvfm/5LLtDw6xu+B2Tw9NxSecO51owd8biKNjhmP7IjVDvoo55m1ZEwSlQs= =mXvX -----END PGP SIGNATURE----- --=-qY0k3IygIQKXYmuQRk/D-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 18:02:24 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E73CE484; Mon, 23 Sep 2013 18:02:24 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C53182E9A; Mon, 23 Sep 2013 18:02:24 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r8NI2KmF083133; Mon, 23 Sep 2013 11:02:20 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201309231802.r8NI2KmF083133@chez.mckusick.com> To: sbruno@freebsd.org, Sean Bruno Subject: Re: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN In-reply-to: <1379951941.1612.3.camel@localhost> Date: Mon, 23 Sep 2013 11:02:20 -0700 From: Kirk McKusick Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:02:25 -0000 > From: Sean Bruno > Subject: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN > To: freebsd-fs > Date: Mon, 23 Sep 2013 08:59:01 -0700 > > So, I'm confused by this check: > > if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - 1) { > error = ENAMETOOLONG; > goto bail; > } > > MFSNAMELEN is 16, why do we check against >= MFSNAMELEN - 1? Why dont > we check against (> MFSNAMELEN - 1) or (>= MFSNAMELEN)? Is a 14 > character fstypelen with a "\0" at the end considered too long? > > Sean > > p.s. e.g. mount -t fuse.glusterfs ... I agree with you. It should either be (> MFSNAMELEN - 1) or (>= MFSNAMELEN). Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 18:19:31 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 783BDF47 for ; Mon, 23 Sep 2013 18:19:31 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C98162FBF for ; Mon, 23 Sep 2013 18:19:30 +0000 (UTC) Received: from ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by relay.ibs.dn.ua with ESMTP id r8NIJLvF020501 for ; Mon, 23 Sep 2013 21:19:22 +0300 (EEST) Message-ID: <20130923211921.20500@relay.ibs.dn.ua> Date: Mon, 23 Sep 2013 21:19:21 +0300 From: "Zeus Panchenko" To: "freebsd-fs@freebsd.org" cc: Subject: ZFS: .eli based vdevs labeling Organization: I.B.S. LLC X-Mailer: MH-E 8.3.1; GNU Mailutils 2.99.98; GNU Emacs 24.0.93 X-Face: &sReWXo3Iwtqql1[My(t1Gkx; y?KF@KF`4X+'9Cs@PtK^y%}^.>Mtbpyz6U=,Op:KPOT.uG )Nvx`=er!l?WASh7KeaGhga"1[&yz$_7ir'cVp7o%CGbJ/V)j/=]vzvvcqcZkf; JDurQG6wTg+?/xA go`}1.Ze//K; Fk&/&OoHd'[b7iGt2UO>o(YskCT[_D)kh4!yY'<&:yt+zM=A`@`~9U+P[qS:f; #9z~ Or/Bo#N-'S'!'[3Wog'ADkyMqmGDvga?WW)qd=?)`Y&k=o}>!ST\ X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Zeus Panchenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:19:31 -0000 hi, please advise NEEDED: for several disk controllers to get zpool of raidzX vdevs, each one on .eli providers QUESTION: what is the most "correct" way to get labels for .eli based devices to be used further in zpool? is it to: gpart create -s gpt daXX.eli gpart add -t freebsd-zfs -l cMdN daXX.eli ? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 22:30:09 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9F075C39 for ; Mon, 23 Sep 2013 22:30:09 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm16-vm2.bullet.mail.ne1.yahoo.com (nm16-vm2.bullet.mail.ne1.yahoo.com [98.138.91.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 245092E96 for ; Mon, 23 Sep 2013 22:30:08 +0000 (UTC) Received: from [98.138.90.56] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 23 Sep 2013 22:30:02 -0000 Received: from [98.138.104.115] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 23 Sep 2013 22:30:02 -0000 Received: from [127.0.0.1] by smtp224.mail.ne1.yahoo.com with NNFMP; 23 Sep 2013 22:30:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379975402; bh=f10VtrWbCrxXiGYwKlFRjiR8iEDdSzrTQdCh7ks0ThE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=IpD3VHTG1WkUUdC4O70ApyggWmmBaMagP2arctx2FBIPWUf7M59f4VgECQIeHr2PZTCg9H0ojaM9o1egncq95IBwdn/ZzuS22NBdZfWyCwc0j8PpaCz0MacC6GPpDnXEvfeo2sC7j56KdSV7K6OMRiczpDzKPOGyojlZPHRCLpA= X-Yahoo-Newman-Id: 116776.64426.bm@smtp224.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NeTdtcIVM1kmsA5.otdtZ8jYesaKBQafCGl45mCeUJg0Mnk rhdnNyzNFzVlOLpUxBUvBKkCZVzTEoXMgnfviYQNkDtTjOaosFc8uQhoULQl a1IpQZGDPQs2gaiXbvp1I25Wkr6Sbm_xcZwxZLtaX9ZU1jeQuDObxr8SbJxB pwfQ17p.m4.aWq4t4gsNfl9K..y4Gu0AF1IAEWYV_XBHtYNU0r858xdI4UnQ V7mEp2kCe_qp2lz0VREu2GUg6cXi5gxl.BjsgaGEGC2_ObeDB_oOGhdIDXp2 1gQgw3fIXeRVbxSor5C4xN7zXKBdaqmE1Ln1vDXkM07U3Wqoi9Bs1xg.A_mb evbzjB9W18WACiusuT5BeHTpRnfqWoY9uDYE3SOfm7J.O7N6WRPQUbW0x.BE voqZe2igTJD5cah1PScooGG4SP7vAH9nu20Hg4z0UkL9KbfK4lvnC7Y53bCu igQJ9ShFowE.QfKPZQLAZlCc4IlJ43hwmO1g2KZ1qIZD6zI8T6wfxg8wVSGg gatK0xHQzCofQq8K1xm7yZ3aisKDmUUGqPX.koAJjbRL1RKiWd92E2cm_Qo_ xcgUQM00- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp224.mail.ne1.yahoo.com with SMTP; 23 Sep 2013 22:30:02 +0000 UTC Subject: ffs(7) out of inodes From: Sean Bruno To: freebsd-fs Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-fctkWLKzMlvja70Nw+li" Date: Mon, 23 Sep 2013 15:30:01 -0700 Message-ID: <1379975401.1593.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 22:30:09 -0000 --=-fctkWLKzMlvja70Nw+li Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Was building a small (5GB) disk image for a MIPS32 QEMU instance to get some image building and testing happening. I'm using FFS for the system as it seemed the lightest option, but even doing a "portsnap fetch" immediately runs out of inodes: # df -hi Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/ada0 5G 413M 4.2G 9% 17k 1 100% / devfs 1.0k 1.0k 0B 100% 0 0 100% /dev My makefs args: makefs -M 5G -B be /portstest/disk.img /portstest/mips/ Sean --=-fctkWLKzMlvja70Nw+li Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSQMDoAAoJEBkJRdwI6BaHb3IIAJEbuLpN+LZl21sbmh9iquMZ jTCBRMcmkO5CE51DIDiSr+qRzmOKDnJln1W13CjmEE+WPqXvw+tlLMPQU+XprmUV BleAV8HWOKgDp6kUHxoyj26vZUeX8cZx/sd9z7ZxHwo6Zb361oju7GN8EEH35E+E WinDXm8U9Ry7hEkCTQjeW1yuhyeNE/E86d6f+TBlNL0Hj4A1+2QM7Wm0jd7FSqTO zQEAfVAv793V498i/BvGNWWrGTAFZ4nc25D4t2YAYWFyWbAzJTK0yLBxuIY4XX2n 27dmnn8Bq3oaQnS/lBjNcJIwNoVytU7ww+kMKY9BAotXYc/8GocirfKefSPx1Vo= =Uqks -----END PGP SIGNATURE----- --=-fctkWLKzMlvja70Nw+li-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 22:35:39 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 13544CE5 for ; Mon, 23 Sep 2013 22:35:39 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm12-vm10.bullet.mail.gq1.yahoo.com (nm12-vm10.bullet.mail.gq1.yahoo.com [98.136.218.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 840FA2EE0 for ; Mon, 23 Sep 2013 22:35:38 +0000 (UTC) Received: from [98.137.12.57] by nm12.bullet.mail.gq1.yahoo.com with NNFMP; 23 Sep 2013 22:33:24 -0000 Received: from [98.136.164.64] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 23 Sep 2013 22:33:24 -0000 Received: from [127.0.0.1] by smtp226.mail.gq1.yahoo.com with NNFMP; 23 Sep 2013 22:33:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379975604; bh=+cFQShgLQBetOY66iUapGjmJHKzf83APIGBf5Du5iCU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=AiE+eC8s68SOy0w6uYwFp+EnMHvC7fCfuWSrvhJUTj29n02YKHaRE5ajsypkHEJ8ZqiTtJ0EHzNHOpXfG8dkWriZY11sslLV4pNQs7E7HvlWjA7Zx+IjUE8WDq7kfYZL6xjmm7Zx+yvZREo3DJmGKg2vPuJ7tx3bUmQ+lcTEdvU= X-Yahoo-Newman-Id: 13541.75021.bm@smtp226.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LD6tuVUVM1mD_AcDWPA8Amb1fhH9PmuUdWUAtXpkuXbAC6v Z7aM_PsUkeB.B6srPfqR16igpNLmDfNGSakAEKM1zuVXR86Vr936IkzYqUcF BaQ.HslLZEI8olMieDocKhNhXFVhucw5Gm9iRtNXEUlrgsoS8uh7oYG.0SFH yFo3T_CIUsd657i9_pziVurHq9GotsCRyz7fUgJ10SS85Hz1u64_czFNFTiR Dg3FG4Ol6LH3rhlC_XP8xrpc8.GjW.vW.Z124_CW2rqXKB4cwtSyETsT2sCS 2XUViWUuwmIdDDZ_iu820bZjxJTA3dNdFK6T99jPplpGOPFIhyA3m7ab6HOl VyFr5hOwb64CfmKFbdi4K9yF6FWsBQbIE6Z9YeMZuLdqhtz.3rUu6.FYVJDr s1M_bH2qnKI851On8j5HRqr5cZAiUdEE7VHZUjV2FjTn2oRfUAbYh4cEiNGI vk6KtVx1Dzmes3RXfgzst_yFb1Vf6eWxxGgqr_Xgrb5L5Ijy1vEfmB5zcShh Mj9t8SJZVai618wCMcBhkvj2872DVCoeKbwCVw5.FYoNKIAVR5pGm6l1Vjld 6Ig-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp226.mail.gq1.yahoo.com with SMTP; 23 Sep 2013 22:33:20 +0000 UTC Subject: Re: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN From: Sean Bruno To: Kirk McKusick In-Reply-To: <201309231802.r8NI2KmF083133@chez.mckusick.com> References: <201309231802.r8NI2KmF083133@chez.mckusick.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-5AbKzWkXOapOU3sB4/Oo" Date: Mon, 23 Sep 2013 15:33:19 -0700 Message-ID: <1379975599.1593.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 22:35:39 -0000 --=-5AbKzWkXOapOU3sB4/Oo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-09-23 at 11:02 -0700, Kirk McKusick wrote: > > So, I'm confused by this check: > >=20 > > if (fstypelen >=3D MFSNAMELEN - 1 || fspathlen >=3D MNAMELEN - > 1) { > > error =3D ENAMETOOLONG; > > goto bail; > > } > >=20 > > MFSNAMELEN is 16, why do we check against >=3D MFSNAMELEN - 1? Why > dont > > we check against (> MFSNAMELEN - 1) or (>=3D MFSNAMELEN)? Is a 14 > > character fstypelen with a "\0" at the end considered too long? > >=20 > > Sean > >=20 > > p.s. e.g. mount -t fuse.glusterfs ... >=20 > I agree with you. It should either be (> MFSNAMELEN - 1) or (>=3D > MFSNAMELEN). >=20 > Kirk McKusick=20 Not sure if we should adjust MNAMELEN or not too while we're at it, I need to do a bit more of a code audit before thunking that one. Propsed patch to set fstyplen check: Index: sys/kern/vfs_mount.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/vfs_mount.c (revision 255831) +++ sys/kern/vfs_mount.c (working copy) @@ -656,7 +656,7 @@ * variables will fit in our mp buffers, including the * terminating NUL. */ - if (fstypelen >=3D MFSNAMELEN - 1 || fspathlen >=3D MNAMELEN - 1) { + if (fstypelen >=3D MFSNAMELEN || fspathlen >=3D MNAMELEN - 1) { error =3D ENAMETOOLONG; goto bail; } --=-5AbKzWkXOapOU3sB4/Oo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSQMGvAAoJEBkJRdwI6BaHimIIAIr5zfdMeMcwtPltANSNazEo T9XvxkgZtNs3GnvmPoY6WdlD6g2gUPIRWs9Ue+xzlwAsvMvFzrISOBj26nLdq17g T2x/S1usoqT5BRPjsXBo1pchLDWDk6171nx/OS3vAd0fzKQ9etO4ziwV2rerMBBO Oe80L3m/tBZo/e20ZSD/+B7eNsGHR1JDOwqfxTw0Utpnc3UUfYpnymiNIMyESrfR iUTFuOurcHG2vpncDyhy6rDn7i4oeZLn6dHRcubVm9ZNeuiHibzo8vdVOrgtNS8T FL+munqot5VSwYTN9i4SQ7ry0Nx77geo232B0wN74ao6fUz0pHvgdOBHLE3TFGA= =CiU4 -----END PGP SIGNATURE----- --=-5AbKzWkXOapOU3sB4/Oo-- From owner-freebsd-fs@FreeBSD.ORG Mon Sep 23 23:06:27 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B4EFE317 for ; Mon, 23 Sep 2013 23:06:27 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4824020AF for ; Mon, 23 Sep 2013 23:06:26 +0000 (UTC) Received: from [98.139.212.153] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 23:06:20 -0000 Received: from [68.142.230.69] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 23:06:20 -0000 Received: from [127.0.0.1] by smtp226.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 23:06:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379977580; bh=wAdeV8ndAjri/OxKmRDKVDRncduvUsDlEclcSFAFgyo=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=ndJ5SAZZBfDndA+wVpj9+7UuITIoxK5vJer8bTC2SZxXgLhEIUn4EdUYNGVbMGDVFwQc2VNEJW3GrUAaP9jZ5Fj7mFQhKdU2qTKTwogWy8+i4/NfiraNd6RBLDgTW8JZHGsCc3c9nH6DL0iOw2BRXxgyXIjM1ES08/zO7pulIec= X-Yahoo-Newman-Id: 161182.82979.bm@smtp226.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: G0RhWNgVM1maiS471uR9OaO36_h.3.rtdc1xG3lU5_nGa0d tcTd_6393KvI6jcqUuVUR3H6cBldJmeMLf_RMXdmei8vkA8Lb.MNCXldFyfr jyWtof4ma_4o1jyb8mtJ3LdMPdgWFgJA.xqOrbAabtg8OPeZpXwsSkb70uiS Di0x118Jgj_QWB7z0310UEMEJ_MEp30qd3J0WfaxJSgDMavjfbh9rfg2vouS qbEFAVuiPtLVBMRdpkEZAqoF2CCrS2C85QhhA_.25TbxXqRLSd7N2wLXpyIb AUj6QHzWlWmfk1PV3n1dPr5VJDGccPObtU_d..1LIcePabKFjcq0aKbmAD1H TV9Z8X..jbSCNjdFt3miZfYi6f0a23PRJqNkibBdwb9fPeV0nxVB0Xa1WzrM yFkOe8yz0OS8AC24dhDLDI7MGGxlvSloYDHuqUz4rsARd6avt6gfLnpuroCv mZUEMBVPzlcDS9qgTk4FQ54FaijpLg47FRav59tL6YM05yV9y_PQ_N05nsrO eGyCkqxv6qxR0KUow4O37cH5WZW0e_cNS87YnHCuq1GS1gWPjL9HDNo03.YE Alw-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp226.mail.bf1.yahoo.com with SMTP; 23 Sep 2013 23:06:20 +0000 UTC Subject: Re: ffs(7) out of inodes [solved by reading the man page again] From: Sean Bruno To: freebsd-fs In-Reply-To: <1379975401.1593.8.camel@localhost> References: <1379975401.1593.8.camel@localhost> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xsQr9tc2eZq2ZxKUx9LD" Date: Mon, 23 Sep 2013 16:06:19 -0700 Message-ID: <1379977579.1593.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 23:06:27 -0000 --=-xsQr9tc2eZq2ZxKUx9LD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mon, 2013-09-23 at 15:30 -0700, Sean Bruno wrote: > Was building a small (5GB) disk image for a MIPS32 QEMU instance to get > some image building and testing happening. >=20 > I'm using FFS for the system as it seemed the lightest option, but even > doing a "portsnap fetch" immediately runs out of inodes: >=20 > # df -hi > Filesystem Size Used Avail Capacity iused ifree %iused Mounted > on > /dev/ada0 5G 413M 4.2G 9% 17k 1 100% / > devfs 1.0k 1.0k 0B 100% 0 0 100% /dev >=20 >=20 > My makefs args: >=20 > makefs -M 5G -B be /portstest/disk.img /portstest/mips/ >=20 > Sean Ah, I needed to read the man page like 100+ times to find the "-f" flag to increase the number of "free" inodes. :-) Sean --=-xsQr9tc2eZq2ZxKUx9LD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSQMlrAAoJEBkJRdwI6BaHcFkH/A9BftfK5k/JfEqH6RZREG+w xfXFp0Isoc15XmgmMILl26Ggbp6v+NYfnAetBWoHegp+6vZ528G9Iq6le6d+uxOl tQUS3gbx23Wsa5/ApRMOhRC6aAxC6z+O/axzQEdjPtlidLKOhKBeddXbo3ULZGKc 1/rDPCK3kOOyvfyfyaQLWXebiu4vyIB4UZn/YjIp6FNx8THXcCN5J00E4ToQhMPT EOMzD5Rb2OCt5xSGxQP2sLVnwisfL25Aid6fwP9bsVmlqr6lctVDTFqDPx5S9iXm GBvWcGXwTZqgWO6R+bX8px/+abfFvYxjoSIkV74lheDW+OmZJ3acSCsD6TXteFA= =0SVo -----END PGP SIGNATURE----- --=-xsQr9tc2eZq2ZxKUx9LD-- From owner-freebsd-fs@FreeBSD.ORG Tue Sep 24 01:17:27 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DA8586E1; Tue, 24 Sep 2013 01:17:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED942660; Tue, 24 Sep 2013 01:17:27 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id DE69B42184D; Tue, 24 Sep 2013 10:48:57 +1000 (EST) Date: Tue, 24 Sep 2013 10:48:45 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: sbruno@FreeBSD.org Subject: Re: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN In-Reply-To: <1379975599.1593.10.camel@localhost> Message-ID: <20130924092642.P954@besplex.bde.org> References: <201309231802.r8NI2KmF083133@chez.mckusick.com> <1379975599.1593.10.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=oauJmmNaXYEA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=kMyxM1bEWncA:10 a=rCNU_45lQ6v1koXlp8QA:9 a=QhwgJvBDTykYGVhM:21 a=QYbaFIYWtEo_1KnJ:21 a=CjuIK1q_8ugA:10 Cc: Kirk McKusick , freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 01:17:27 -0000 On Mon, 23 Sep 2013, Sean Bruno wrote: > On Mon, 2013-09-23 at 11:02 -0700, Kirk McKusick wrote: >>> So, I'm confused by this check: >>> >>> if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - >> 1) { >>> error = ENAMETOOLONG; >>> goto bail; >>> } >>> >>> MFSNAMELEN is 16, why do we check against >= MFSNAMELEN - 1? Why >> dont >>> we check against (> MFSNAMELEN - 1) or (>= MFSNAMELEN)? Is a 14 >>> character fstypelen with a "\0" at the end considered too long? >>> >>> Sean >>> >>> p.s. e.g. mount -t fuse.glusterfs ... >> >> I agree with you. It should either be (> MFSNAMELEN - 1) or (>= >> MFSNAMELEN). Apart from the existence of this check being a bug, it is still off by 1 for fstypename and off by 2 for fspathlen. It used to be off by 2 for both. fstypelen and fsnamelen are not string lengths; they are array sizes where the array includes space for the terminating NUL (you can see this most easily a few lines earlier where it is checked that the byte at the end is NUL, where the end is determined by these variables). MFSNAMELEN and MNAMELEN are also not string lengths; they are also array sizes where the array includes space for the terminating NUL. Thus fstypelen == MFSNAMELEN and fspathlen == MNAMELEN are maximal non-lengths, not errors. "fuse.glusterfs" happens to have length 14 and size 15, so it is is maximal for the off-by-1 limit. > Not sure if we should adjust MNAMELEN or not too while we're at it, I > need to do a bit more of a code audit before thunking that one. The existence of the MNAMELEN check is a bug. It breaks mounting of file systems when fspathlen is too long to fit in the copy of the pathname that will be returned by statfs() if statfs() is ever called (except with the off-by-2 bug it breaks even for pathnames that fit). mount() worked correctly in old versions of FreeBSD -- pathnames were only limited by MAXPATHLEN, except where they are copied to struct statfs and possibly to superblocks (where they array reserved for the pathname is typically also too short, but not as short as MNAMELEN). Utilities using statfs() couldn't report correct pathnames for truncated ones, and the full pathname needed to be remembered somewhere if unmount() needs to be by pathname, but that is better than not allowing the mount at all. The MFSNAMELEN check doesn't break anything, but is just silly. fstype just points to a full copy of a mount arg and isn't copied to any array of limited length MFSNAMELEN. It is only used to look up the file system in vfs_byname() or vfs_byname_kld(). If the caller is silly enough to try to mount a file system whose name length (plus 1) exceeds MFSNAMELEN, then the lookup obviously fails since the name is longer than the name of any file system that can be supported. The relevant bounds check is in vfs_buildopts() where the arg is copied in. vfs_mount.c now has internal dependencies on the buggy up-front MNAMELEN limit, but these should be easy to fix by using the correct limit MAXPATHLEN everywhere except where the pathname is copied to the statfs struct. This copying used to be repeated in individual file systems, but is now centralized in vfs_mount_alloc(), and it still explicitly truncates although truncation is now always null due to the up-front check. > Propsed patch to set fstyplen check: > Index: sys/kern/vfs_mount.c > =================================================================== > --- sys/kern/vfs_mount.c (revision 255831) > +++ sys/kern/vfs_mount.c (working copy) > @@ -656,7 +656,7 @@ > * variables will fit in our mp buffers, including the > * terminating NUL. > */ > - if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - 1) { > + if (fstypelen >= MFSNAMELEN || fspathlen >= MNAMELEN - 1) { > error = ENAMETOOLONG; > goto bail; > } The correct checks for implenting this bug are simpler and more natural: if (fstypelen > MFSNAMELEN || fspathlen > MNAMELEN) { These buggy checks are repeated at the start of vfs_domount(), except the checks there use strlen() and are naturally missing the off-by-[12] errors: if (strlen(fstype) >= MFSNAMELEN || strlen(fspath) >= MNAMELEN) Bruce From owner-freebsd-fs@FreeBSD.ORG Tue Sep 24 09:42:24 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 36B12276; Tue, 24 Sep 2013 09:42:24 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F13BC2E97; Tue, 24 Sep 2013 09:42:23 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r8O9gKna000550; Tue, 24 Sep 2013 02:42:20 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201309240942.r8O9gKna000550@chez.mckusick.com> To: Bruce Evans Subject: Re: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN In-reply-to: <20130924092642.P954@besplex.bde.org> Date: Tue, 24 Sep 2013 02:42:20 -0700 From: Kirk McKusick Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 09:42:24 -0000 > Date: Tue, 24 Sep 2013 10:48:45 +1000 (EST) > From: Bruce Evans > To: sbruno@FreeBSD.org > cc: Kirk McKusick , freebsd-fs > Subject: Re: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN > > On Mon, 23 Sep 2013, Sean Bruno wrote: > >> On Mon, 2013-09-23 at 11:02 -0700, Kirk McKusick wrote: >>>> So, I'm confused by this check: >>>> >>>> if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - >>> 1) { >>>> error = ENAMETOOLONG; >>>> goto bail; >>>> } >>>> >>>> MFSNAMELEN is 16, why do we check against >= MFSNAMELEN - 1? Why >>> dont >>>> we check against (> MFSNAMELEN - 1) or (>= MFSNAMELEN)? Is a 14 >>>> character fstypelen with a "\0" at the end considered too long? >>>> >>>> Sean >>>> >>>> p.s. e.g. mount -t fuse.glusterfs ... >>> >>> I agree with you. It should either be (> MFSNAMELEN - 1) or (>= >>> MFSNAMELEN). > > Apart from the existence of this check being a bug, it is still off by > 1 for fstypename and off by 2 for fspathlen. It used to be off by 2 > for both. > > fstypelen and fsnamelen are not string lengths; they are array sizes > where the array includes space for the terminating NUL (you can see > this most easily a few lines earlier where it is checked that the byte > at the end is NUL, where the end is determined by these variables). > MFSNAMELEN and MNAMELEN are also not string lengths; they are also array > sizes where the array includes space for the terminating NUL. Thus > fstypelen == MFSNAMELEN and fspathlen == MNAMELEN are maximal non-lengths, > not errors. > > "fuse.glusterfs" happens to have length 14 and size 15, so it is is maximal > for the off-by-1 limit. > >> Not sure if we should adjust MNAMELEN or not too while we're at it, I >> need to do a bit more of a code audit before thunking that one. > > The existence of the MNAMELEN check is a bug. It breaks mounting of file > systems when fspathlen is too long to fit in the copy of the pathname > that will be returned by statfs() if statfs() is ever called (except with > the off-by-2 bug it breaks even for pathnames that fit). mount() worked > correctly in old versions of FreeBSD -- pathnames were only limited by > MAXPATHLEN, except where they are copied to struct statfs and possibly > to superblocks (where the array reserved for the pathname is typically > also too short, but not as short as MNAMELEN). Utilities using statfs() > couldn't report correct pathnames for truncated ones, and the full > pathname needed to be remembered somewhere if unmount() needs to be by > pathname, but that is better than not allowing the mount at all. > > The MFSNAMELEN check doesn't break anything, but is just silly. fstype > just points to a full copy of a mount arg and isn't copied to any array > of limited length MFSNAMELEN. It is only used to look up the file > system in vfs_byname() or vfs_byname_kld(). If the caller is silly > enough to try to mount a file system whose name length (plus 1) exceeds > MFSNAMELEN, then the lookup obviously fails since the name is longer > than the name of any file system that can be supported. The relevant > bounds check is in vfs_buildopts() where the arg is copied in. > > vfs_mount.c now has internal dependencies on the buggy up-front MNAMELEN > limit, but these should be easy to fix by using the correct limit > MAXPATHLEN everywhere except where the pathname is copied to the statfs > struct. This copying used to be repeated in individual file systems, > but is now centralized in vfs_mount_alloc(), and it still explicitly > truncates although truncation is now always null due to the up-front > check. > >> Propsed patch to set fstyplen check: >> Index: sys/kern/vfs_mount.c >> =================================================================== >> --- sys/kern/vfs_mount.c (revision 255831) >> +++ sys/kern/vfs_mount.c (working copy) >> @@ -656,7 +656,7 @@ >> * variables will fit in our mp buffers, including the >> * terminating NUL. >> */ >> - if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - 1) { >> + if (fstypelen >= MFSNAMELEN || fspathlen >= MNAMELEN - 1) { >> error = ENAMETOOLONG; >> goto bail; >> } > > The correct checks for implementing this bug are simpler and more natural: > > if (fstypelen > MFSNAMELEN || fspathlen > MNAMELEN) { > > These buggy checks are repeated at the start of vfs_domount(), except > the checks there use strlen() and are naturally missing the off-by-[12] > errors: > > if (strlen(fstype) >= MFSNAMELEN || strlen(fspath) >= MNAMELEN) > > Bruce I agree with Bruce's arguments and his proposed solution. Notably the change should be: Index: sys/kern/vfs_mount.c =================================================================== --- sys/kern/vfs_mount.c (revision 255831) +++ sys/kern/vfs_mount.c (working copy) @@ -656,7 +656,7 @@ * variables will fit in our mp buffers, including the * terminating NUL. */ - if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - 1) { + if (fstypelen > MFSNAMELEN || fspathlen > MNAMELEN) { error = ENAMETOOLONG; goto bail; } From owner-freebsd-fs@FreeBSD.ORG Wed Sep 25 03:07:11 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D8F8C396; Wed, 25 Sep 2013 03:07:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8751220D8; Wed, 25 Sep 2013 03:07:11 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 95612781EA1; Wed, 25 Sep 2013 12:43:17 +1000 (EST) Date: Wed, 25 Sep 2013 12:43:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kirk McKusick Subject: Re: kern/vfs_mount.c vfs_donmount() checks of MFSNAMELEN In-Reply-To: <201309240942.r8O9gKna000550@chez.mckusick.com> Message-ID: <20130925120938.C995@besplex.bde.org> References: <201309240942.r8O9gKna000550@chez.mckusick.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=YYGEuWhf c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=oauJmmNaXYEA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=kMyxM1bEWncA:10 a=FUyLlYIt_FMkiQppwXAA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 03:07:11 -0000 On Tue, 24 Sep 2013, Kirk McKusick wrote: >> Date: Tue, 24 Sep 2013 10:48:45 +1000 (EST) >> From: Bruce Evans >> ... >> Apart from the existence of this check being a bug, it is still off by >> 1 for fstypename and off by 2 for fspathlen. It used to be off by 2 >> for both. >> ... >> The existence of the MNAMELEN check is a bug. It breaks mounting of file >> systems when fspathlen is too long to fit in the copy of the pathname >> that will be returned by statfs() if statfs() is ever called (except with >> the off-by-2 bug it breaks even for pathnames that fit). mount() worked >> correctly in old versions of FreeBSD -- pathnames were only limited by >> MAXPATHLEN, except where they are copied to struct statfs and possibly >> ... > I agree with Bruce's arguments and his proposed solution. Notably the > change should be: > > Index: sys/kern/vfs_mount.c > =================================================================== > --- sys/kern/vfs_mount.c (revision 255831) > +++ sys/kern/vfs_mount.c (working copy) > @@ -656,7 +656,7 @@ > * variables will fit in our mp buffers, including the > * terminating NUL. > */ > - if (fstypelen >= MFSNAMELEN - 1 || fspathlen >= MNAMELEN - 1) { > + if (fstypelen > MFSNAMELEN || fspathlen > MNAMELEN) { > error = ENAMETOOLONG; > goto bail; > } Also (regarding the excessive limiting), ENAMETOOLONG is a documented error for fspath in mount.2, but the documentation only mentions the usual {PATH_MAX} and {NAME_MAX} limits, where as usual {PATH_MAX} and {NAME_MAX} are not mentioned but their values less 1 are hard-coded as 1023 and 255 respectively, so the above error is undocumented even for fspath. For fstype, the error is just undocumented since the documentation is only about path names but fstype is not a path name. Bruce From owner-freebsd-fs@FreeBSD.ORG Wed Sep 25 09:03:05 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7C07A438 for ; Wed, 25 Sep 2013 09:03:05 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09FD82416 for ; Wed, 25 Sep 2013 09:03:04 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id o14so4733190lbi.18 for ; Wed, 25 Sep 2013 02:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=wK/2Pp6m3RmAwM6QuDZv+kIdBgIFxfmqlPh4rKA+9Cs=; b=jBnn1As3lD+pirejK7u36NsB0kZDy4vfNvPrC/IMQnb/xCQBNZ53s81Kf44xEY+dTw rwDQg7YL878RCTHAJ2A0WW2kfbcFrW+nPViRZXYhKemibNblT+7KCrSg+NT0VKkXiZFn E9Cn6GLjn5jsc7a2tSjI7AGIUPAmpQqMr2fCXm6itsA63uu4EAcV4iba92qbRZMzNa92 4VHKuczDiWWjuHY385jTUkVrcTzdJ9LEt7KB+fr8Qxx+5yBe2W72pnFNeNvwMHk9Tm+R xBQqRs27C77fKolF9WxzLBD0CVC7GtzUxG3REVFK68wkBZA4G/fSotzqcGHAZFhyQay8 /HTw== X-Received: by 10.112.72.229 with SMTP id g5mr28528761lbv.10.1380099782910; Wed, 25 Sep 2013 02:03:02 -0700 (PDT) Received: from [192.168.1.130] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id u20sm18219938lbh.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 02:03:02 -0700 (PDT) Message-ID: <5242A6C5.6050303@gmail.com> Date: Wed, 25 Sep 2013 12:03:01 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-fs Subject: DEBUG mode and ZFS arc size Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 09:03:05 -0000 Hi all. I have some problems on one of my machines and I have recompiled kernel there with: option KDB option KDB_TRACE option KDB_UNATTENDED option DDB option DEBUG_MEMGUARD option DEBUG_REDZONE option INVARIANTS option INVARIANT_SUPPORT option DIAGNOSTIC option WITNESS option WITNESS_SKIPSPIN Before this ZFS can take gigs of memory (there are 64Gb RAM on the server) but now it only takes not more than 4Gb. Am I missing something in my configuration or is this the way it should work? -- Sphinx of black quartz, judge my vow. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 25 10:05:54 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F11097E for ; Wed, 25 Sep 2013 10:05:54 +0000 (UTC) (envelope-from prvs=1980632278=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4B7C289E for ; Wed, 25 Sep 2013 10:05:53 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006099332.msg for ; Wed, 25 Sep 2013 11:05:33 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 25 Sep 2013 11:05:33 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1980632278=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.org Message-ID: <55037589FFAB471E87B1450DBBE6A8AB@multiplay.co.uk> From: "Steven Hartland" To: "Volodymyr Kostyrko" , "freebsd-fs" References: <5242A6C5.6050303@gmail.com> Subject: Re: DEBUG mode and ZFS arc size Date: Wed, 25 Sep 2013 11:05:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 10:05:54 -0000 INVARIANTS on head enables ZFS debugging which may be changing something but its not expected if it does so more info on this would be needed. "zfs-stats -a" would be a good place to start Regards Steve ----- Original Message ----- From: "Volodymyr Kostyrko" To: "freebsd-fs" Sent: Wednesday, September 25, 2013 10:03 AM Subject: DEBUG mode and ZFS arc size > Hi all. > > I have some problems on one of my machines and I have recompiled kernel > there with: > > option KDB > option KDB_TRACE > option KDB_UNATTENDED > option DDB > > option DEBUG_MEMGUARD > option DEBUG_REDZONE > > option INVARIANTS > option INVARIANT_SUPPORT > option DIAGNOSTIC > > option WITNESS > option WITNESS_SKIPSPIN > > Before this ZFS can take gigs of memory (there are 64Gb RAM on the > server) but now it only takes not more than 4Gb. Am I missing something > in my configuration or is this the way it should work? > > -- > Sphinx of black quartz, judge my vow. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Wed Sep 25 12:10:22 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81AB2C6B for ; Wed, 25 Sep 2013 12:10:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E0F42075 for ; Wed, 25 Sep 2013 12:10:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8PCAMBT096528 for ; Wed, 25 Sep 2013 12:10:22 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8PCAL1Q096527 for freebsd-fs@FreeBSD.org; Wed, 25 Sep 2013 12:10:21 GMT (envelope-from bdrewery) Received: (qmail 48289 invoked from network); 25 Sep 2013 07:10:20 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 25 Sep 2013 07:10:20 -0500 Message-ID: <5242D2A6.1000002@FreeBSD.org> Date: Wed, 25 Sep 2013 07:10:14 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Subject: Why does devfs allow unlinking /dev/*? (kern/139014) X-Enigmail-Version: 1.5.2 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3ot1bEbiFTNApI8rSxQlO4wOVBSWpv9Kq" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:10:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3ot1bEbiFTNApI8rSxQlO4wOVBSWpv9Kq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see that devfs_remove() allows anything to be removed and always returns 0. This causes problems for package building as many ports will run 'gcc -o /dev/null file.c' which removes /dev/null. Simple rm /dev/null also works. Of course 'rm /dev/*' works as well. After this is done, 'dev rule apply path unhide' is needed to restore the files. Why is this allowed? Does this belong on arch@ instead? --=20 Regards, Bryan Drewery --3ot1bEbiFTNApI8rSxQlO4wOVBSWpv9Kq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQtKmAAoJEG54KsA8mwz5jccP/jh7GlRrTXyN/9brt3wkDURA fOwHrlFDdaz+wlNFxZqGhqI0E+CvATpXIf4qoHP1vDnjqJUAznoFfuOyUPkZai3Y g4Ab6lrn4625Jyy3WKUxkJmWFKR7y8TyTm2I2ONY9TO5MyYpyFcrO7Bfytvj/l/l yIQOHO90KzNrTIgG2G3Qc/NjgoMp7atYX0Pwx1bUdPY/sUAEPCE0NKcGOs61lswI OKZWo3kq89IUvlnLPALS5yyXqnD540F2qPU2IgaubPszyXnlKB+bWDowsnnJycFt 9DbyploVnzLBsGr4nI37STOB8YYrIlkT2cVRVb2vxfnNXEZW21dsyhtt7/16mYpf h6873Q0tgEl+NJtHQiVkG+Ps4LIq/ZBSkY2MnEQndJX2daNSZHGgNtOoMw15xK65 X1Hwx2X35ec6ngmWpNBb17QqEOttpok3SP6uY5sGmtYkiMkT634tlEfjU2cBuSgJ AUkfUJDsgX5KUo3EjxgYo3U85HAlpgyKk9FsPAAVUwvOB7JEk2GHmnPGRN1iIJBS zlEMScLgH4a54gH/B+5lOzIwYHNuKgBKk3Kt1UvZ8HQX4jdv0JKju6YQQFv5Yg5X rksc1uYzO8VfWfQmO7dRHzJ/Cftgz1HbRyTb+px2O6g9SJDmMn8gPLIjqnaButZr tmmoOFhuJ5zlJMHK0Zjo =bgbo -----END PGP SIGNATURE----- --3ot1bEbiFTNApI8rSxQlO4wOVBSWpv9Kq-- From owner-freebsd-fs@FreeBSD.ORG Wed Sep 25 13:54:13 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5E3D33F2; Wed, 25 Sep 2013 13:54:13 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews08.kpnxchange.com (cpsmtpb-ews08.kpnxchange.com [213.75.39.13]) by mx1.freebsd.org (Postfix) with ESMTP id CAFFD2761; Wed, 25 Sep 2013 13:54:12 +0000 (UTC) Received: from cpsps-ews22.kpnxchange.com ([10.94.84.188]) by cpsmtpb-ews08.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 25 Sep 2013 15:53:02 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews22.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 25 Sep 2013 15:53:01 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 25 Sep 2013 15:53:01 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id DC011604; Wed, 25 Sep 2013 15:53:00 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, "Mateusz Guzik" Date: Wed, 25 Sep 2013 15:52:59 +0200 Subject: nandfs fills up without activity MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 25 Sep 2013 13:53:01.0472 (UTC) FILETIME=[8CBEA200:01CEB9F6] X-RcptDomain: freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 13:54:13 -0000 Hello, I still have this issue on an up-to-date 10-ALPHA2 Sheevaplug. My / is on nandfs with tmpfs as /tmp and /var symlinked to an ufs usb-stick. So there is almost no activity on /. This is the table from a periodic cron. Filesystem 1024-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/gnand0s.root 515328 416896 98432 81% 12612 0 100% / /dev/gnand0s.root 515328 417536 97792 81% 12612 0 100% / /dev/gnand0s.root 515328 417792 97536 81% 12612 0 100% / Du does not give a difference in allocated space for reachable files. A reboot does not free space so I don't suspect a deleted file. In the mentioned thread (about a year ago) Mateusz said he can reproduce the problem. So I cc him. Ronald. -- old info about the same issue is copy-pasted below -- On Sun, 30 Dec 2012 15:17:56 +0100, Ronald Klop wrote: > Mateusz, > > I found this similar issue from last november. > http://freebsd.1045724.n5.nabble.com/NANDFS-eats-itself-up-td5764878.html > Do you have anything new about this? I'm willing to test anything. > > Regards, > Ronald. > > On Sun, 30 Dec 2012 13:55:02 +0100, Ronald Klop > wrote: > >> Hi, >> >> I just noticed my nandfs is filling up on a clean install. >> Running a sheevaplug. >> FreeBSD sh10.klop.ws 10.0-CURRENT FreeBSD 10.0-CURRENT #10: Sat Dec 15 >> 18:26:46 CET 2012 >> root@mailjail.klop.ws:/usr/obj/arm.arm/usr/src/sys/SHEEVAPLUG arm >> >> From the daily messages to root. >> Disk status: >> Filesystem Size Used Avail Capacity Mounted on >> root@sh10:/var/mail # grep gnand root >> /dev/gnand0s.root 503M 286M 216M 57% / >> /dev/gnand0s.root 503M 299M 203M 59% / >> /dev/gnand0s.root 503M 316M 187M 63% / >> /dev/gnand0s.root 503M 329M 173M 65% / >> /dev/gnand0s.root 503M 341M 161M 68% / >> /dev/gnand0s.root 503M 341M 161M 68% / >> /dev/gnand0s.root 503M 353M 149M 70% / >> /dev/gnand0s.root 503M 363M 139M 72% / >> /dev/gnand0s.root 503M 375M 127M 75% / >> /dev/gnand0s.root 503M 388M 114M 77% / >> /dev/gnand0s.root 503M 399M 103M 79% / >> /dev/gnand0s.root 503M 412M 91M 82% / >> /dev/gnand0s.root 503M 423M 79M 84% / >> /dev/gnand0s.root 503M 435M 68M 86% / >> /dev/gnand0s.root 503M 446M 57M 89% / >> >> I did not activate any useful daemons. >> root@sh10:/var/mail # cat /etc/rc.conf >> hostname="sh10.klop.ws" >> ifconfig_DEFAULT="DHCP" >> >> fsck_y_enable="YES" >> background_fsck="NO" >> >> sshd_enable="YES" >> ntpd_enable="YES" >> ntpd_sync_on_start="YES" >> >> I just rebooted the machine to make sure no deleted files are still >> open. >> Df still shows 51MB available while du only shows 227MB in use. >> What can be happening here? >> >> Ronald. >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed Sep 25 19:32:57 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8DDA7176 for ; Wed, 25 Sep 2013 19:32:57 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 509C82DB8 for ; Wed, 25 Sep 2013 19:32:57 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5b:71c5:b3bc:c366]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id B43BF4AC58; Wed, 25 Sep 2013 23:32:55 +0400 (MSK) Date: Wed, 25 Sep 2013 23:32:48 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <138452559.20130925233248@serebryakov.spb.ru> To: Kirk McKusick Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-Reply-To: <201309222224.r8MMO2o7025466@chez.mckusick.com> References: <724152380.20130921144811@serebryakov.spb.ru> <201309222224.r8MMO2o7025466@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs , Jeff Roberson X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:32:57 -0000 Hello, Kirk. You wrote 23 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= 2:24:02: KM> Have you run a manual (fsck -f) on the affected filesystems? If so, KM> was it able to clean them up? If not, please do so and save the output KM> of fsck (using script command is usually the easiest way to do this). I've stopped server and checked two FSes with WTITE errors (/ and /usr) with fsck -f, but it didn't find any errors at all. I have / dumped (completely, as binary blob) and could upload it when I find and mask all passwords :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu Sep 26 06:12:12 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 400E97AA; Thu, 26 Sep 2013 06:12:12 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 198032E40; Thu, 26 Sep 2013 06:12:12 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r8Q6C7kj086301; Wed, 25 Sep 2013 23:12:07 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201309260612.r8Q6C7kj086301@chez.mckusick.com> To: lev@FreeBSD.org Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-reply-to: <138452559.20130925233248@serebryakov.spb.ru> Date: Wed, 25 Sep 2013 23:12:07 -0700 From: Kirk McKusick Cc: freebsd-fs , Jeff Roberson X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 06:12:12 -0000 > Date: Wed, 25 Sep 2013 23:32:48 +0400 > From: Lev Serebryakov > To: Kirk McKusick > CC: Jeff Roberson , > freebsd-fs > Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. > > Hello, Kirk. > You wrote 23 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= > 2:24:02: > > > KM> Have you run a manual (fsck -f) on the affected filesystems? If so, > KM> was it able to clean them up? If not, please do so and save the output > KM> of fsck (using script command is usually the easiest way to do this). > I've stopped server and checked two FSes with WTITE errors (/ and /usr) > with fsck -f, but it didn't find any errors at all. > I have / dumped (completely, as binary blob) and could upload it when I > find and mask all passwords :) > > --=20 > // Black Lion AKA Lev Serebryakov I do not think that we are likely to find out anything useful from looking at your dumpped /. Notably the errors that were produced were because an indirect block had gottened trashed. Looking at the file image is not going to tell us how they got trashed. Usual cases are memory errors, address line errors on the I/O bus, or I/O error in the disk itself. The journal does not know of these errors, so does not look to correct them. Hence the need for a manual fsck. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Thu Sep 26 11:46:59 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8E195A06 for ; Thu, 26 Sep 2013 11:46:59 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4CDF824FE for ; Thu, 26 Sep 2013 11:46:58 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5b:71c5:b3bc:c366]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id ECFE74AC57; Thu, 26 Sep 2013 15:46:54 +0400 (MSK) Date: Thu, 26 Sep 2013 15:46:47 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1537848823.20130926154647@serebryakov.spb.ru> To: Kirk McKusick Subject: Re: Strange UFS write problem & SU+J "unexpected inconsistences" on 9.1-STABLE r253105 after it on OTHER filesystems. In-Reply-To: <201309260612.r8Q6C7kj086301@chez.mckusick.com> References: <138452559.20130925233248@serebryakov.spb.ru> <201309260612.r8Q6C7kj086301@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs , Jeff Roberson X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 11:46:59 -0000 Hello, Kirk. You wrote 26 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2013 =D0=B3.,= 10:12:07: KM> I do not think that we are likely to find out anything useful from KM> looking at your dumpped /. Notably the errors that were produced were KM> because an indirect block had gottened trashed. Looking at the file KM> image is not going to tell us how they got trashed. Usual cases are KM> memory errors, address line errors on the I/O bus, or I/O error in the KM> disk itself. The journal does not know of these errors, so does not KM> look to correct them. Hence the need for a manual fsck. Kirk, I want to bring into focus, that EINVAL writes were seen for / and /var (which leaded to panic and reboot), and fsck after panic failed for /u= sr and /tmp. So, you words "The journal does not know of these errors, so does not look to correct them." is not belong here. Journal was unable to correct errors on FSes which didn't have any problems at moment of panic! And after all, full fsck didn't find any problems with indirect blocks on / and /var later (yesterday). I repeat again: journal problems were seen on filesystems, which didn't have any visible problems at moment of panic. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Fri Sep 27 12:29:49 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A2012F66 for ; Fri, 27 Sep 2013 12:29:49 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5336328E0 for ; Fri, 27 Sep 2013 12:29:48 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 46EE311B88DE; Fri, 27 Sep 2013 14:29:40 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.350304, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 9.1069] X-CRM114-CacheID: sfid-20130927_14293_669B5939 X-CRM114-Status: Good ( pR: 9.1069 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Sep 27 14:29:40 2013 X-DSPAM-Confidence: 0.7002 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52457a3441081262551121 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, zfs, 0.00481, zfs, 0.00481, From*Attila, 0.00529, says+the, 0.00529, Subject*system, 0.00661, To*FreeBSD.org, 0.00682, 0+53, 0.00879, If+not, 0.00958, Received*online.co.hu+[195.228.243.99]), 0.01000, STATE, 0.99000, Received*[195.228.243.99]), 0.01000, Received*online.co.hu, 0.01000, From*Attila+Nagy, 0.01000, Subject*zfs, 0.01000, USED, 0.99000, Received*(japan.t, 0.01000, es+on, 0.99000, From*Nagy+; Fri, 27 Sep 2013 14:29:39 +0200 (CEST) Message-ID: <52457A32.2090105@fsn.hu> Date: Fri, 27 Sep 2013 14:29:38 +0200 From: Attila Nagy MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org Subject: zfs: the exponential file system from hell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 12:29:49 -0000 Hi, Did anyone try to fill a zpool with multiple zfs in it and graph the space accounted by df and zpool list? If not, here it is: https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#5928271443977601554 The zpool in question: NAME STATE READ WRITE CKSUM mnt ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 raidz2-1 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 raidz2-2 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10 ONLINE 0 0 0 da11 ONLINE 0 0 0 da13 ONLINE 0 0 0 And the zfs-es on it: NAME USED AVAIL REFER MOUNTPOINT mnt 23.3G 0 53.8K /mnt mnt/p1 3.89G 0 3.89G /mnt/p1 mnt/p2 3.89G 0 3.89G /mnt/p2 mnt/p3 3.89G 0 3.89G /mnt/p3 mnt/p4 3.89G 0 3.89G /mnt/p4 mnt/p5 3.89G 0 3.89G /mnt/p5 mnt/p6 3.89G 0 3.89G /mnt/p6 I have evenly filled the six zfs in 1/100th percents of the full space available, and graphed the results of zpool list's capacity and df's capacity. The x scale is the real space usage in percents. It's quite annoying when df says the file systems are 20% full, while in reality, they are at 60%. Any chance that it will be solved? From owner-freebsd-fs@FreeBSD.ORG Fri Sep 27 13:05:43 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7EF36C10 for ; Fri, 27 Sep 2013 13:05:43 +0000 (UTC) (envelope-from prvs=1982cd6be2=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C2532B73 for ; Fri, 27 Sep 2013 13:05:42 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006123864.msg for ; Fri, 27 Sep 2013 14:05:33 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 27 Sep 2013 14:05:33 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1982cd6be2=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@FreeBSD.org Message-ID: <34A97DEE00E94B1F8EC3028B61BEF621@multiplay.co.uk> From: "Steven Hartland" To: "Attila Nagy" , References: <52457A32.2090105@fsn.hu> Subject: Re: the exponential file system from hell Date: Fri, 27 Sep 2013 14:05:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:05:43 -0000 Pro tip don't use an insulting subject if your looking for help. Regards Steve ----- Original Message ----- From: "Attila Nagy" To: Sent: Friday, September 27, 2013 1:29 PM Subject: zfs: the exponential file system from hell > Hi, > > Did anyone try to fill a zpool with multiple zfs in it and graph the > space accounted by df and zpool list? > If not, here it is: > https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#5928271443977601554 > > The zpool in question: > NAME STATE READ WRITE CKSUM > mnt ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > raidz2-1 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > raidz2-2 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > da11 ONLINE 0 0 0 > da13 ONLINE 0 0 0 > > And the zfs-es on it: > NAME USED AVAIL REFER MOUNTPOINT > mnt 23.3G 0 53.8K /mnt > mnt/p1 3.89G 0 3.89G /mnt/p1 > mnt/p2 3.89G 0 3.89G /mnt/p2 > mnt/p3 3.89G 0 3.89G /mnt/p3 > mnt/p4 3.89G 0 3.89G /mnt/p4 > mnt/p5 3.89G 0 3.89G /mnt/p5 > mnt/p6 3.89G 0 3.89G /mnt/p6 > > I have evenly filled the six zfs in 1/100th percents of the full space > available, and graphed the results of zpool list's capacity and df's > capacity. > The x scale is the real space usage in percents. > > It's quite annoying when df says the file systems are 20% full, while in > reality, they are at 60%. > > Any chance that it will be solved? > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 27 13:12:38 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6ACB9F4F for ; Fri, 27 Sep 2013 13:12:38 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DA7172C63 for ; Fri, 27 Sep 2013 13:12:37 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 5B64111B8C4F; Fri, 27 Sep 2013 15:12:35 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.043537, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 20.2516] X-CRM114-CacheID: sfid-20130927_15123_3B9BC496 X-CRM114-Status: Good ( pR: 20.2516 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Sep 27 15:12:35 2013 X-DSPAM-Confidence: 0.9961 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52458443244761751524857 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, FreeBSD, 0.00069, of+>, 0.00144, it+>, 0.00190, in+>, 0.00197, wrote+>, 0.00204, >+>>, 0.00300, >>+>, 0.00303, >>+I, 0.00332, >+>, 0.00351, >+>, 0.00351, References*fsn.hu>, 0.00354, FreeBSD+org>, 0.00379, >>+>>, 0.00393, >>+>>, 0.00393, zfs, 0.00481, zfs, 0.00481, >>+Hi, 0.00481, don't+use, 0.00481, it+or, 0.00529, wrote, 0.00529, >+it, 0.00529, From*Attila, 0.00529, says+the, 0.00529, Subject*system, 0.00661, To*FreeBSD.org, 0.00682, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 00A1111B8C3F; Fri, 27 Sep 2013 15:12:33 +0200 (CEST) Message-ID: <52458441.8010802@fsn.hu> Date: Fri, 27 Sep 2013 15:12:33 +0200 From: Attila Nagy MIME-Version: 1.0 To: Steven Hartland , freebsd-fs@FreeBSD.org Subject: Re: the exponential file system from hell References: <52457A32.2090105@fsn.hu> <34A97DEE00E94B1F8EC3028B61BEF621@multiplay.co.uk> In-Reply-To: <34A97DEE00E94B1F8EC3028B61BEF621@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:12:38 -0000 It's just meant to be funny, sorry if you find it insulting. On 09/27/13 15:05, Steven Hartland wrote: > Pro tip don't use an insulting subject if your looking for help. > > Regards > Steve > ----- Original Message ----- From: "Attila Nagy" > To: > Sent: Friday, September 27, 2013 1:29 PM > Subject: zfs: the exponential file system from hell > > >> Hi, >> >> Did anyone try to fill a zpool with multiple zfs in it and graph the >> space accounted by df and zpool list? >> If not, here it is: >> https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#5928271443977601554 >> >> >> The zpool in question: >> NAME STATE READ WRITE CKSUM >> mnt ONLINE 0 0 0 >> raidz2-0 ONLINE 0 0 0 >> da1 ONLINE 0 0 0 >> da2 ONLINE 0 0 0 >> da3 ONLINE 0 0 0 >> da4 ONLINE 0 0 0 >> raidz2-1 ONLINE 0 0 0 >> da5 ONLINE 0 0 0 >> da6 ONLINE 0 0 0 >> da7 ONLINE 0 0 0 >> da8 ONLINE 0 0 0 >> raidz2-2 ONLINE 0 0 0 >> da9 ONLINE 0 0 0 >> da10 ONLINE 0 0 0 >> da11 ONLINE 0 0 0 >> da13 ONLINE 0 0 0 >> >> And the zfs-es on it: >> NAME USED AVAIL REFER MOUNTPOINT >> mnt 23.3G 0 53.8K /mnt >> mnt/p1 3.89G 0 3.89G /mnt/p1 >> mnt/p2 3.89G 0 3.89G /mnt/p2 >> mnt/p3 3.89G 0 3.89G /mnt/p3 >> mnt/p4 3.89G 0 3.89G /mnt/p4 >> mnt/p5 3.89G 0 3.89G /mnt/p5 >> mnt/p6 3.89G 0 3.89G /mnt/p6 >> >> I have evenly filled the six zfs in 1/100th percents of the full >> space available, and graphed the results of zpool list's capacity and >> df's capacity. >> The x scale is the real space usage in percents. >> >> It's quite annoying when df says the file systems are 20% full, while >> in reality, they are at 60%. >> >> Any chance that it will be solved? >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From owner-freebsd-fs@FreeBSD.ORG Fri Sep 27 13:54:09 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BAA3E62C for ; Fri, 27 Sep 2013 13:54:09 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews09.kpnxchange.com (cpsmtpb-ews09.kpnxchange.com [213.75.39.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9D422BE for ; Fri, 27 Sep 2013 13:54:08 +0000 (UTC) Received: from cpsps-ews01.kpnxchange.com ([10.94.84.168]) by cpsmtpb-ews09.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 15:52:57 +0200 Received: from CPSMTPM-TLF101.kpnxchange.com ([195.121.3.4]) by cpsps-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 15:52:57 +0200 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF101.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Sep 2013 15:52:57 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id D8D8B984 for ; Fri, 27 Sep 2013 15:52:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: zfs: the exponential file system from hell References: <52457A32.2090105@fsn.hu> Date: Fri, 27 Sep 2013 15:52:56 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <52457A32.2090105@fsn.hu> User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 27 Sep 2013 13:52:57.0474 (UTC) FILETIME=[DF301620:01CEBB88] X-RcptDomain: freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:54:09 -0000 On Fri, 27 Sep 2013 14:29:38 +0200, Attila Nagy wrote: > Hi, > > Did anyone try to fill a zpool with multiple zfs in it and graph the > space accounted by df and zpool list? > If not, here it is: > https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#5928271443977601554 > > The zpool in question: > NAME STATE READ WRITE CKSUM > mnt ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > raidz2-1 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > raidz2-2 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > da11 ONLINE 0 0 0 > da13 ONLINE 0 0 0 > > And the zfs-es on it: > NAME USED AVAIL REFER MOUNTPOINT > mnt 23.3G 0 53.8K /mnt > mnt/p1 3.89G 0 3.89G /mnt/p1 > mnt/p2 3.89G 0 3.89G /mnt/p2 > mnt/p3 3.89G 0 3.89G /mnt/p3 > mnt/p4 3.89G 0 3.89G /mnt/p4 > mnt/p5 3.89G 0 3.89G /mnt/p5 > mnt/p6 3.89G 0 3.89G /mnt/p6 > > I have evenly filled the six zfs in 1/100th percents of the full space > available, and graphed the results of zpool list's capacity and df's > capacity. > The x scale is the real space usage in percents. > > It's quite annoying when df says the file systems are 20% full, while in > reality, they are at 60%. > > Any chance that it will be solved? So, if I understand you correctly, you compare the output of free space of zpool list (of the whole pool) to the output of df of one of size zfs's. So the conclusion is that zpool list shows you how much space there is in the pool and df shows the amount-of-space-of-one-zfs-if-you-don't-do-change-other-zfs's-in-the-pool-in-the-meantime. This is not going to be fixed. It is by design. Choose the best tool to measure what you want to know. But I understand it is a bit confusing if you come from traditional fixed-size filesystems. You can emulate a fixed-size filesystem by using quota's. Give all zfs's 1/6 of the space in quota and your df will work perfectly. NB: I'm not a ZFS developer so I don't have an authoritative opinion about all this. Regards, Ronald. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 27 14:07:31 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E21AAACB for ; Fri, 27 Sep 2013 14:07:31 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B726A23DB for ; Fri, 27 Sep 2013 14:07:31 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4148321A27 for ; Fri, 27 Sep 2013 10:07:28 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Fri, 27 Sep 2013 10:07:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=A+4eNKFInA0wNuFKnsOYkVf7cVY=; b=fl6 2Ba3wuCJj6zatYQY48PSQCqwSolW9s9aQhOfrTNtjgZkCY0f1VZUwshLQpyWKcNZ MSm41AlWGALGeGN3qBYPiUYYNXe1wwzl2g+2ZZe6PZf7rPhP3O0pLt2wg21OIx1f +rELnDUL0tJ3u8euoUKiTmkHzRnQQcTgpLElngfw= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 19AC6B0013C; Fri, 27 Sep 2013 10:07:28 -0400 (EDT) Message-Id: <1380290848.21485.27200049.4E9FF5C6@webmail.messagingengine.com> X-Sasl-Enc: BPVjd9oL9p+Z/seO8+3vm+hN3Uahe1TlsuUMbbLmWH4M 1380290848 From: Mark Felder To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: <52457A32.2090105@fsn.hu> References: <52457A32.2090105@fsn.hu> Subject: Re: zfs: the exponential file system from hell Date: Fri, 27 Sep 2013 09:07:28 -0500 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 14:07:31 -0000 On Fri, Sep 27, 2013, at 7:29, Attila Nagy wrote: > Hi, > > Did anyone try to fill a zpool with multiple zfs in it and graph the > space accounted by df and zpool list? If you're using zfs, use zfs tools for space accounting. df probably shouldn't be bloated with special knowledge of zfs's space accounting quirks. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 27 15:00:31 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3C94C175 for ; Fri, 27 Sep 2013 15:00:31 +0000 (UTC) (envelope-from lkchen@k-state.edu) Received: from ksu-out.merit.edu (ksu-out.merit.edu [207.75.117.133]) by mx1.freebsd.org (Postfix) with ESMTP id CA8A6275E for ; Fri, 27 Sep 2013 15:00:30 +0000 (UTC) X-Merit-ExtLoop1: 1 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFOcRVLPS3TT/2dsb2JhbABagwc4UoMpvj4WdIIlAQEFI2IPGAICDRkCWRmIBgyZDY8EiROJDwSBKYxxBIFQglSBNgObVY4ig0CBTUE X-IronPort-AV: E=Sophos;i="4.90,993,1371096000"; d="scan'208";a="166652002" X-MERIT-SOURCE: KSU Received: from ksu-sfpop-mailstore02.merit.edu ([207.75.116.211]) by sfpop-ironport01.merit.edu with ESMTP; 27 Sep 2013 10:57:54 -0400 Date: Fri, 27 Sep 2013 10:56:49 -0400 (EDT) From: "Lawrence K. Chen, P.Eng." To: freebsd-fs@freebsd.org Message-ID: <378297647.87296597.1380293809297.JavaMail.root@k-state.edu> In-Reply-To: Subject: Re: zfs: the exponential file system from hell MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [70.179.133.134] X-Mailer: Zimbra 7.2.2_GA_2852 (ZimbraWebClient - GC29 ([unknown])/7.2.2_GA_2852) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 15:00:31 -0000 ----- Original Message ----- > On Fri, 27 Sep 2013 14:29:38 +0200, Attila Nagy wrote: > > > Hi, > > > > Did anyone try to fill a zpool with multiple zfs in it and graph > > the > > space accounted by df and zpool list? > > If not, here it is: > > https://picasaweb.google.com/104147045962330059540/FreeBSDZfsVsDf#5928271443977601554 > > > > The zpool in question: > > NAME STATE READ WRITE CKSUM > > mnt ONLINE 0 0 0 > > raidz2-0 ONLINE 0 0 0 > > da1 ONLINE 0 0 0 > > da2 ONLINE 0 0 0 > > da3 ONLINE 0 0 0 > > da4 ONLINE 0 0 0 > > raidz2-1 ONLINE 0 0 0 > > da5 ONLINE 0 0 0 > > da6 ONLINE 0 0 0 > > da7 ONLINE 0 0 0 > > da8 ONLINE 0 0 0 > > raidz2-2 ONLINE 0 0 0 > > da9 ONLINE 0 0 0 > > da10 ONLINE 0 0 0 > > da11 ONLINE 0 0 0 > > da13 ONLINE 0 0 0 > > > > And the zfs-es on it: > > NAME USED AVAIL REFER MOUNTPOINT > > mnt 23.3G 0 53.8K /mnt > > mnt/p1 3.89G 0 3.89G /mnt/p1 > > mnt/p2 3.89G 0 3.89G /mnt/p2 > > mnt/p3 3.89G 0 3.89G /mnt/p3 > > mnt/p4 3.89G 0 3.89G /mnt/p4 > > mnt/p5 3.89G 0 3.89G /mnt/p5 > > mnt/p6 3.89G 0 3.89G /mnt/p6 > > > > I have evenly filled the six zfs in 1/100th percents of the full > > space > > available, and graphed the results of zpool list's capacity and > > df's > > capacity. > > The x scale is the real space usage in percents. > > > > It's quite annoying when df says the file systems are 20% full, > > while in > > reality, they are at 60%. > > > > Any chance that it will be solved? > > So, if I understand you correctly, you compare the output of free > space of > zpool list (of the whole pool) to the output of df of one of size > zfs's. > So the conclusion is that zpool list shows you how much space there > is in > the pool and df shows the > amount-of-space-of-one-zfs-if-you-don't-do-change-other-zfs's-in-the-pool-in-the-meantime. > > This is not going to be fixed. It is by design. Choose the best tool > to > measure what you want to know. > But I understand it is a bit confusing if you come from traditional > fixed-size filesystems. > You can emulate a fixed-size filesystem by using quota's. Give all > zfs's > 1/6 of the space in quota and your df will work perfectly. > > NB: I'm not a ZFS developer so I don't have an authoritative opinion > about > all this. > > Regards, > Ronald. zpool list gives raw storage space. Whereas zfs list and df would deal in terms of usable fs space. And, a given block set, for raidz2, is N data blocks, plus 2 parity blocks, where N+2 <= total disks in vdev. Which can further complicate the conversion of raw storage to usable. (plus there's additional metadata if you make changes to only some of the data blocks in a block set...and more overhead since the old block set has to stay around until all its data blocks are orphaned.) -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally From owner-freebsd-fs@FreeBSD.ORG Sat Sep 28 20:06:48 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80030F41 for ; Sat, 28 Sep 2013 20:06:48 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF0F42FC7 for ; Sat, 28 Sep 2013 20:06:47 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 8F32411C6F1E; Sat, 28 Sep 2013 22:06:38 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 17.1007] X-CRM114-CacheID: sfid-20130928_22063_EDFE8DD1 X-CRM114-Status: Good ( pR: 17.1007 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Sep 28 22:06:38 2013 X-DSPAM-Confidence: 0.9961 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 524736ce807201965525328 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, the+>, 0.00084, of+>, 0.00144, is+>, 0.00171, wrote+>, 0.00204, >+You, 0.00253, all+>, 0.00332, >+in, 0.00332, >+>, 0.00351, References*fsn.hu>, 0.00354, >+So, 0.00354, >+So, 0.00354, the+output, 0.00354, the+output, 0.00354, I+understand, 0.00379, I+understand, 0.00379, to+fix, 0.00408, zfs, 0.00481, output+of, 0.00529, output+of, 0.00529, filesystem, 0.00529, wrote, 0.00529, From*Attila, 0.00529, >+But, 0.00588, Subject*system, 0.00661, output, 0.00675, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 94FD311C6F0D; Sat, 28 Sep 2013 22:06:34 +0200 (CEST) Message-ID: <524736C6.9010205@fsn.hu> Date: Sat, 28 Sep 2013 22:06:30 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Ronald Klop , freebsd-fs@freebsd.org Subject: Re: zfs: the exponential file system from hell References: <52457A32.2090105@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 20:06:48 -0000 On 09/27/2013 03:52 PM, Ronald Klop wrote: > > So, if I understand you correctly, you compare the output of free > space of zpool list (of the whole pool) to the output of df of one of > size zfs's. Yes. > So the conclusion is that zpool list shows you how much space there is > in the pool and df shows the > amount-of-space-of-one-zfs-if-you-don't-do-change-other-zfs's-in-the-pool-in-the-meantime. Almost, it wasn't about the free space, but the capacity. > But I understand it is a bit confusing if you come from traditional > fixed-size filesystems. Yes, for machines, which rely on df's output. :) That's what happened here, and that's where an otherwise linear fill up went exponential. I've been asked about it, and graphed it, because it looked funny. > You can emulate a fixed-size filesystem by using quota's. Give all > zfs's 1/6 of the space in quota and your df will work perfectly. Agreed, that's the easiest way to fix this.