From owner-freebsd-fs@FreeBSD.ORG Sun Mar 20 21:53:01 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03AF7106564A; Sun, 20 Mar 2011 21:53:01 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CE83F8FC16; Sun, 20 Mar 2011 21:53:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2KLr0jQ044210; Sun, 20 Mar 2011 21:53:00 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2KLr0YU044206; Sun, 20 Mar 2011 21:53:00 GMT (envelope-from arundel) Date: Sun, 20 Mar 2011 21:53:00 GMT Message-Id: <201103202153.p2KLr0YU044206@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/146205: [zfs] df(1) fails to display total space on a 100PB filesystem correctly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 21:53:01 -0000 Old Synopsis: df(1) fails to display total space on a 100PB filesystem correctly New Synopsis: [zfs] df(1) fails to display total space on a 100PB filesystem correctly Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: arundel Responsible-Changed-When: Sun Mar 20 21:42:44 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=146205 From owner-freebsd-fs@FreeBSD.ORG Sun Mar 20 21:53:41 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 420151065673; Sun, 20 Mar 2011 21:53:41 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD498FC1F; Sun, 20 Mar 2011 21:53:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2KLreFL044265; Sun, 20 Mar 2011 21:53:40 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2KLrefQ044261; Sun, 20 Mar 2011 21:53:40 GMT (envelope-from arundel) Date: Sun, 20 Mar 2011 21:53:40 GMT Message-Id: <201103202153.p2KLrefQ044261@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-bugs@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/146205: df(1) fails to display total space on a 100PB filesystem correctly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 21:53:41 -0000 Old Synopsis: [zfs] df(1) fails to display total space on a 100PB filesystem correctly New Synopsis: df(1) fails to display total space on a 100PB filesystem correctly Responsible-Changed-From-To: freebsd-fs->freebsd-bugs Responsible-Changed-By: arundel Responsible-Changed-When: Sun Mar 20 21:53:03 UTC 2011 Responsible-Changed-Why: Sorry my bad. http://www.freebsd.org/cgi/query-pr.cgi?pr=146205 From owner-freebsd-fs@FreeBSD.ORG Mon Mar 21 09:07:50 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6569106564A for ; Mon, 21 Mar 2011 09:07:50 +0000 (UTC) (envelope-from ed.stout@streamvia.net) Received: from zcs01.streamvia.com (zcs01.streamvia.com [178.63.87.235]) by mx1.freebsd.org (Postfix) with ESMTP id 81F608FC0A for ; Mon, 21 Mar 2011 09:07:50 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs01.streamvia.com (Postfix) with ESMTP id DAB3514257D for ; Mon, 21 Mar 2011 08:49:45 +0000 (GMT) X-Virus-Scanned: amavisd-new at zcs01.streamvia.com Received: from zcs01.streamvia.com ([127.0.0.1]) by localhost (zcs01.streamvia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su9VlsiIgdVP for ; Mon, 21 Mar 2011 08:49:42 +0000 (GMT) Received: from zcs01.streamvia.com (zcs01.streamvia.com [178.63.87.235]) by zcs01.streamvia.com (Postfix) with ESMTP id DC780142590 for ; Mon, 21 Mar 2011 08:49:42 +0000 (GMT) Date: Mon, 21 Mar 2011 08:49:42 -0000 (GMT) From: iMx To: freebsd-fs@freebsd.org Message-ID: <437685da-9247-4e35-9b95-b4ce255a062e@zcs01> In-Reply-To: MIME-Version: 1.0 X-Originating-IP: [212.119.4.226] X-Mailer: Zimbra 7.0.1_GA_3105 (ZimbraWebClient - SAF3 (Win)/7.0.1_GA_3105) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: zfs v28 - 8.2 Release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 09:07:50 -0000 Morning, Ive applied the patch for v28 for FreeBSD 8.2 - however do i now need to perform essentially a 'make world' (albeit not doing just that, but doing things in the right order ;)? I am currently using the mfsbsd ISO with it pre-compiled, but need to recompile the kernel for ALTQ support - can i just rebuild the kernel? Or would checking out the source from sysinstall and updating result in a zfs module that does not support v28? Which i would expect.... If someone could point me in the right direction it would be much appreciated. Thanks, iMx From owner-freebsd-fs@FreeBSD.ORG Mon Mar 21 11:06:57 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1A21065691 for ; Mon, 21 Mar 2011 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D76588FC28 for ; Mon, 21 Mar 2011 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2LB6umh085971 for ; Mon, 21 Mar 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2LB6ubJ085968 for freebsd-fs@FreeBSD.org; Mon, 21 Mar 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Mar 2011 11:06:56 GMT Message-Id: <201103211106.p2LB6ubJ085968@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 Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 11:06:57 -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/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs o kern/155484 fs [ufs] GPT + UFS boot don't work well together o 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 o kern/154447 fs [zfs] [panic] Occasional panics - solaris assert somew f 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/153847 fs [nfs] [panic] Kernel panic from incorrect m_free in nf 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/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable 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 kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small p kern/152488 fs [tmpfs] [patch] mtime of file updated when only inode o kern/152079 fs [msdosfs] [patch] Small cleanups from the other NetBSD 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 kern/151845 fs [smbfs] [patch] smbfs should be upgraded to support Un 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/151111 fs [zfs] vnodes leakage during zfs unmount 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/150207 fs zpool(1): zpool import -d /dev tries to open weird dev o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa f kern/149022 fs [hang] File system operations hangs with suspfs state 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 bin/148296 fs [zfs] [loader] [patch] Very slow probe in /usr/src/sys o kern/148204 fs [nfs] UDP NFS causes overload 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/147790 fs [zfs] zfs set acl(mode|inherit) fails on existing zfs o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take 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 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 o 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/142914 fs [zfs] ZFS performance degradation over time 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/142401 fs [ntfs] [patch] Minor updates to NTFS from NetBSD 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/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( 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/140134 fs [msdosfs] write and fsck destroy filesystem integrity 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/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo 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/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 o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int 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/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 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 bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [ffs] [snapshot] System crashes when manipulat 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 bin/118249 fs [ufs] mv(1): moving a directory changes its mtime 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/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani 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 kern/116170 fs [panic] Kernel panic when mounting /tmp 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 kern/109024 fs [msdosfs] [iconv] mount_msdosfs: msdosfs_iconv: Operat o kern/109010 fs [msdosfs] can't mv directory within fat32 file system 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/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk 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 kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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/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/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/33464 fs [ufs] soft update inconsistencies after system crash 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 220 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Mar 21 17:19:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93CED106566C for ; Mon, 21 Mar 2011 17:19:27 +0000 (UTC) (envelope-from lists@loveturtle.net) Received: from loveturtle.net (unknown [IPv6:2605:5a00:0:666::1]) by mx1.freebsd.org (Postfix) with ESMTP id BD99C8FC0C for ; Mon, 21 Mar 2011 17:19:26 +0000 (UTC) Received: from loveturtle.net (localhost [127.0.0.1]) by loveturtle.net (Postfix) with ESMTP id AB3C1255F for ; Mon, 21 Mar 2011 12:19:24 -0500 (EST) X-Virus-Scanned: amavisd-new at loveturtle.net Received: from loveturtle.net ([127.0.0.1]) by loveturtle.net (loveturtle.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNWjMcfzjSWF for ; Mon, 21 Mar 2011 12:19:22 -0500 (EST) Received: from vier.loveturtle.net (vier.loveturtle.net [216.182.254.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by loveturtle.net (Postfix) with ESMTPS id 6FA362544 for ; Mon, 21 Mar 2011 12:19:22 -0500 (EST) From: Dillon Kass Date: Mon, 21 Mar 2011 13:19:22 -0400 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 8.2-R & ZFSv28 & zfs destroy -r X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:19:27 -0000 Hello. Sorry if this has already been mentioned (and/or fixed), I = browsed the list archive and didn't see anything...=20 I just applied releng-8.2-zfsv28-20110317.patch.xz to 8.2-R and all = seems well but I noticed a zfs destroy -r bug..=20 It used to be if you had a snapshot say rpool/test@monday you could = issue zfs destroy -r rpool@monday and it would delete the snapshot even = though rpool@monday doesn't exist.=20 for example.. turtle@solaris11vm:~# zfs list -t all -r rpool1/test NAME USED AVAIL REFER MOUNTPOINT rpool1/test 127K 6.34G 34K /rpool1/test rpool1/test@testsnap 0 - 34K - rpool1/test/test2 31K 6.34G 31K /rpool1/test/test2 rpool1/test/test2@testsnap 0 - 31K - rpool1/test/test3 31K 6.34G 31K /rpool1/test/test3 rpool1/test/test3@testsnap 0 - 31K - rpool1/test/test4 31K 6.34G 31K /rpool1/test/test4 rpool1/test/test4@testsnap 0 - 31K - turtle@solaris11vm:~# zfs destroy -r rpool1@testsnap turtle@solaris11vm:~# zfs list -t all -r rpool1/test NAME USED AVAIL REFER MOUNTPOINT rpool1/test 127K 6.34G 34K /rpool1/test rpool1/test/test2 31K 6.34G 31K /rpool1/test/test2 rpool1/test/test3 31K 6.34G 31K /rpool1/test/test3 rpool1/test/test4 31K 6.34G 31K /rpool1/test/test4 turtle@solaris11vm:~#=20 However, after updating I noticed zfSnap was unable to destroy my = snapshots. It seems like this isn't working anymore.. loveturtle zfsnap # zfs snapshot -r lt/home@testsnap loveturtle zfsnap # zfs destroy -r lt@testsnap cannot destroy 'lt@testsnap': dataset does not exist no snapshots destroyed zsh: exit 1 zfs destroy -r lt@testsnap loveturtle zfsnap # zfs destroy -r lt/home@testsnap loveturtle zfsnap #=20 :-(= From owner-freebsd-fs@FreeBSD.ORG Wed Mar 23 02:26:17 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92BEE1065672 for ; Wed, 23 Mar 2011 02:26:17 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 59AD58FC1E for ; Wed, 23 Mar 2011 02:26:17 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 39ABB7E8D6 for ; Wed, 23 Mar 2011 13:26:15 +1100 (EST) Message-ID: <4D895A46.8030409@freebsd.org> Date: Wed, 23 Mar 2011 13:26:14 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Subject: Deterministic unionfs panic triggered by kern_renameat() on 8.2-STABLE X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 02:26:17 -0000 Hi all, I'm playing around with the changes to the ISO building infrastructure which Nathan Whitehorn has most recently been tweaking. I've built an ISO which runs as its first rc.d script the set of commands to create a unionfs over the top of the read only /etc. This is obviously desirable as it allows anything which attempts to write to /etc (e.g. hostid, sshd, dhclinet) to work transparently. Everything works great - system rc.d startup works, I can create files in /etc, edit existing files using ee, run dhclient without any command line switches etc. However, when I use vim to edit a file, it obviously uses a different syscall (kern_renameat) to any of the other programs I've tested, which triggers a deterministic panic. A screenshot of the panic from virtualbox and a basic reproduction recipe are available at [1]. Any thoughts on how to fix the locking? Cheers, Lawrence [1] http://people.freebsd.org/~lstewart/misc/unionfs_debug/ From owner-freebsd-fs@FreeBSD.ORG Wed Mar 23 06:06:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03AEA1065686 for ; Wed, 23 Mar 2011 06:06:13 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id BBC388FC17 for ; Wed, 23 Mar 2011 06:06:12 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 5CAAD7E8D6 for ; Wed, 23 Mar 2011 16:48:21 +1100 (EST) Message-ID: <4D8989A5.1020203@swin.edu.au> Date: Wed, 23 Mar 2011 16:48:21 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Subject: mount -o union doesn't allow changes to sub directories? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 06:06:13 -0000 Hi again, If I run something like: mount -o union /dev/md0 /etc where md0 is a memory backed fs device, and /etc is fully populated but mounted RO off a CD, I can touch a new file in /etc, but can't in any subdir of etc (fails with "Read-only filesystem" reported). As far as I can tell this is a bug, but wanted to check if I'm misunderstanding how the "-o union" mount option is supposed to work. Cheers, Lawrence From owner-freebsd-fs@FreeBSD.ORG Wed Mar 23 06:16:43 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96FE510656A3 for ; Wed, 23 Mar 2011 06:16:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC768FC08 for ; Wed, 23 Mar 2011 06:16:43 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta02.emeryville.ca.mail.comcast.net with comcast id NWFl1g0011afHeLA2WGisa; Wed, 23 Mar 2011 06:16:42 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.emeryville.ca.mail.comcast.net with comcast id NWGh1g00C1t3BNj8dWGh0D; Wed, 23 Mar 2011 06:16:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0E8FF9B422; Tue, 22 Mar 2011 23:16:41 -0700 (PDT) Date: Tue, 22 Mar 2011 23:16:41 -0700 From: Jeremy Chadwick To: Lawrence Stewart Message-ID: <20110323061641.GA74977@icarus.home.lan> References: <4D8989A5.1020203@swin.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8989A5.1020203@swin.edu.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: mount -o union doesn't allow changes to sub directories? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 06:16:43 -0000 On Wed, Mar 23, 2011 at 04:48:21PM +1100, Lawrence Stewart wrote: > Hi again, > > If I run something like: > > mount -o union /dev/md0 /etc > > where md0 is a memory backed fs device, and /etc is fully populated but > mounted RO off a CD, I can touch a new file in /etc, but can't in any > subdir of etc (fails with "Read-only filesystem" reported). > > As far as I can tell this is a bug, but wanted to check if I'm > misunderstanding how the "-o union" mount option is supposed to work. Please see mount_unionfs(8), specifically the explanations of "lower" and "upper" layers, along with EROFS (errno 30, "Read-only filesystem"). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Wed Mar 23 06:30:02 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 498FB1065676 for ; Wed, 23 Mar 2011 06:30:02 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 01AB48FC1B for ; Wed, 23 Mar 2011 06:30:01 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id B7E4E7E8D5; Wed, 23 Mar 2011 17:30:00 +1100 (EST) Message-ID: <4D899368.9090709@swin.edu.au> Date: Wed, 23 Mar 2011 17:30:00 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.15) Gecko/20110308 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D8989A5.1020203@swin.edu.au> <20110323061641.GA74977@icarus.home.lan> In-Reply-To: <20110323061641.GA74977@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-fs@freebsd.org Subject: Re: mount -o union doesn't allow changes to sub directories? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 06:30:02 -0000 Hi Jeremy, On 03/23/11 17:16, Jeremy Chadwick wrote: > On Wed, Mar 23, 2011 at 04:48:21PM +1100, Lawrence Stewart wrote: >> Hi again, >> >> If I run something like: >> >> mount -o union /dev/md0 /etc >> >> where md0 is a memory backed fs device, and /etc is fully populated but >> mounted RO off a CD, I can touch a new file in /etc, but can't in any >> subdir of etc (fails with "Read-only filesystem" reported). >> >> As far as I can tell this is a bug, but wanted to check if I'm >> misunderstanding how the "-o union" mount option is supposed to work. > > Please see mount_unionfs(8), specifically the explanations of "lower" > and "upper" layers, along with EROFS (errno 30, "Read-only filesystem"). I don't think 'mount -o union' is the same thing as doing a unionfs mount. Earlier today I was playing with unionfs and it worked perfectly for the scenario I describe above. 'mount -o union' seems to do something similar, but subtly different to unionfs. The key difference from the UI perspective is that unionfs can be used to mount a directory on top of another directory, whereas using 'mount -o union' requires you to mount a device with an fs on it on top of a directory. The semantics of 'mount -o union' are far more useful for my situation that unionfs, so I'm keen to try and see if I can get it working properly, which I suspect will involve a kernel patch. Cheers, Lawrence From owner-freebsd-fs@FreeBSD.ORG Wed Mar 23 06:38:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85371065698 for ; Wed, 23 Mar 2011 06:38:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id AD5558FC15 for ; Wed, 23 Mar 2011 06:38:06 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta11.emeryville.ca.mail.comcast.net with comcast id NWWU1g0061ZMdJ4ABWe6Z3; Wed, 23 Mar 2011 06:38:06 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta16.emeryville.ca.mail.comcast.net with comcast id NWe51g0011t3BNj8cWe50g; Wed, 23 Mar 2011 06:38:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0B1829B422; Tue, 22 Mar 2011 23:38:05 -0700 (PDT) Date: Tue, 22 Mar 2011 23:38:05 -0700 From: Jeremy Chadwick To: Lawrence Stewart Message-ID: <20110323063805.GA75312@icarus.home.lan> References: <4D8989A5.1020203@swin.edu.au> <20110323061641.GA74977@icarus.home.lan> <4D899368.9090709@swin.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D899368.9090709@swin.edu.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: mount -o union doesn't allow changes to sub directories? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 06:38:06 -0000 On Wed, Mar 23, 2011 at 05:30:00PM +1100, Lawrence Stewart wrote: > Hi Jeremy, > > On 03/23/11 17:16, Jeremy Chadwick wrote: > > On Wed, Mar 23, 2011 at 04:48:21PM +1100, Lawrence Stewart wrote: > >> Hi again, > >> > >> If I run something like: > >> > >> mount -o union /dev/md0 /etc > >> > >> where md0 is a memory backed fs device, and /etc is fully populated but > >> mounted RO off a CD, I can touch a new file in /etc, but can't in any > >> subdir of etc (fails with "Read-only filesystem" reported). > >> > >> As far as I can tell this is a bug, but wanted to check if I'm > >> misunderstanding how the "-o union" mount option is supposed to work. > > > > Please see mount_unionfs(8), specifically the explanations of "lower" > > and "upper" layers, along with EROFS (errno 30, "Read-only filesystem"). > > I don't think 'mount -o union' is the same thing as doing a unionfs > mount. Earlier today I was playing with unionfs and it worked perfectly > for the scenario I describe above. 'mount -o union' seems to do > something similar, but subtly different to unionfs. > > The key difference from the UI perspective is that unionfs can be used > to mount a directory on top of another directory, whereas using 'mount > -o union' requires you to mount a device with an fs on it on top of a > directory. > > The semantics of 'mount -o union' are far more useful for my situation > that unionfs, so I'm keen to try and see if I can get it working > properly, which I suspect will involve a kernel patch. You're right -- MNT_UNION (which is what -o mount makes use of) is different than UNIONFS. How this plays with the kernel is unknown to me (I've skimmed the code, it's over my head since it's VFS). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Wed Mar 23 14:37:34 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB144106567D for ; Wed, 23 Mar 2011 14:37:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 474C08FC14 for ; Wed, 23 Mar 2011 14:37:33 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2NEbTdt008254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 16:37:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2NEbTpK026352; Wed, 23 Mar 2011 16:37:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2NEbTTf026351; Wed, 23 Mar 2011 16:37:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Mar 2011 16:37:29 +0200 From: Kostik Belousov To: Lawrence Stewart Message-ID: <20110323143729.GA78089@deviant.kiev.zoral.com.ua> References: <4D8989A5.1020203@swin.edu.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bNaxTB0Vnic66+5h" Content-Disposition: inline In-Reply-To: <4D8989A5.1020203@swin.edu.au> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: mount -o union doesn't allow changes to sub directories? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:37:34 -0000 --bNaxTB0Vnic66+5h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2011 at 04:48:21PM +1100, Lawrence Stewart wrote: > Hi again, >=20 > If I run something like: >=20 > mount -o union /dev/md0 /etc >=20 > where md0 is a memory backed fs device, and /etc is fully populated but > mounted RO off a CD, I can touch a new file in /etc, but can't in any > subdir of etc (fails with "Read-only filesystem" reported). >=20 > As far as I can tell this is a bug, but wanted to check if I'm > misunderstanding how the "-o union" mount option is supposed to work. No, this is how the union mount work. Union is performed only on the mount point directory, for the names that are absent in the directory. --bNaxTB0Vnic66+5h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2KBagACgkQC3+MBN1Mb4gJPwCfU2LOeCrR3O+fmArlSLOxdHZ4 67UAoL/sMPUkLoMS7UJ5QSlxss3wMhyT =fP+l -----END PGP SIGNATURE----- --bNaxTB0Vnic66+5h-- From owner-freebsd-fs@FreeBSD.ORG Thu Mar 24 16:53:57 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C651065674 for ; Thu, 24 Mar 2011 16:53:57 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70BFB8FC17 for ; Thu, 24 Mar 2011 16:53:57 +0000 (UTC) Received: by gxk28 with SMTP id 28so82122gxk.13 for ; Thu, 24 Mar 2011 09:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wOzuftvJdnKvXcjW+QFt+KNZDwuXVG/XIixYFUCT/i8=; b=pPer2ey4UzcLA1FckAfDouWG+m041Orl5L2hvc4PI4fV5OAe2d3aXjjiia3wMT0zK0 k6N+9pG88P8rDX+ytYoMa3jjDhajn3i6BNicPbPVTiMaEgsdC4Qkq5dmbJCYQWYkVvuP /ny52UV5PgUKqcfNmk7LtEhPJIhD7NKLfRObc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AzwrXcOTtg3A7WiZQ7p8XizNChetto1wAAiBi1XvDvQ4ijlpFoG0pAJH/gHXRfpe/2 mLO8qkGARvP+A1M9DF0vFDWSE4ADVPdLCz4QuAjtKEhcb1et2ARSR9vrhi9/d6up48ti s9x4JOpQtyXDLLFdE0XBomgzK8GgYkMuujpi4= MIME-Version: 1.0 Received: by 10.90.156.12 with SMTP id d12mr7855174age.46.1300985636656; Thu, 24 Mar 2011 09:53:56 -0700 (PDT) Received: by 10.90.100.10 with HTTP; Thu, 24 Mar 2011 09:53:56 -0700 (PDT) In-Reply-To: <437685da-9247-4e35-9b95-b4ce255a062e@zcs01> References: <437685da-9247-4e35-9b95-b4ce255a062e@zcs01> Date: Thu, 24 Mar 2011 09:53:56 -0700 Message-ID: From: Freddie Cash To: iMx Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zfs v28 - 8.2 Release X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 16:53:57 -0000 On Mon, Mar 21, 2011 at 1:49 AM, iMx wrote: > Ive applied the patch for v28 for FreeBSD 8.2 - however do i now need to = perform essentially a 'make world' (albeit not doing just that, but doing t= hings in the right order ;)? Update/download the source tree. Apply the ZFSv28 patch to the source tree. Go through a buildworld, buildkernel, installkernel, installworld cycle. Test that you have ZFSv28. Then you can create a custom kernel configuration file, and do a buildkernel/installkernel cycle to install the new kernel. > I am currently using the mfsbsd ISO with it pre-compiled, but need to rec= ompile the kernel for ALTQ support - can i just rebuild the kernel? Or woul= d checking out the source from sysinstall and updating result in a zfs modu= le that does not support v28? Which i would expect.... Don't use sysinstall once the system is installed. Use the tools that come with the OS (csup, svn, portsnap, freebsd-update, etc). Trying to use sysinstall after the syste is installed will cause you no end of grief. It's not a system management tool. Don't try to use it like one. :) > If someone could point me in the right direction it would be much appreci= ated. See above. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Mar 24 20:36:34 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD12F106564A; Thu, 24 Mar 2011 20:36:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62E828FC14; Thu, 24 Mar 2011 20:36:34 +0000 (UTC) Received: by yie12 with SMTP id 12so198233yie.13 for ; Thu, 24 Mar 2011 13:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=GEu1jejOrTUik9GdpGN0Z6dh0xDfYf38cuz4CuVrtQg=; b=PGFf5w9NF+tY2I06FVEmd0ef02Y1x4wx9ixWCs5KhTWeNFYA1mazTtgPTflOOLSj7D oYo6OYBAFBlsx6vemxMQ1wzat1P/k3yjpNKqcVM80n9oGV9s3+0MHl8wkQYZctRoPcOt spNfgvq4NzvzV1/ROh9w8PbcQn15CrDzroo7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=h/pPwYaXpIgTL0vePcbdoQyzrar2v7klZZBDWKn5V0McF4PBe9QEFh49gkdcrJc5Y+ wCIX/Oms/VcHDVuY57Pat2rqRk0sqlSkT7aKhELRyAJhVst7zhb7ZZaYL858082YXaGr R9QELutEwdLPEIxd9E9MwjAev5iueF9MQAbsg= MIME-Version: 1.0 Received: by 10.91.20.12 with SMTP id x12mr7990825agi.100.1300998992801; Thu, 24 Mar 2011 13:36:32 -0700 (PDT) Received: by 10.90.100.10 with HTTP; Thu, 24 Mar 2011 13:36:32 -0700 (PDT) Date: Thu, 24 Mar 2011 13:36:32 -0700 Message-ID: From: Freddie Cash To: FreeBSD-Current Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Filesystems , FreeBSD Stable Subject: Any success stories for HAST + ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 20:36:35 -0000 [Not sure which list is most appropriate since it's using HAST + ZFS on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on replies.] I'm having a hell of a time making this work on real hardware, and am not ruling out hardware issues as yet, but wanted to get some reassurance that someone out there is using this combination (FreeBSD + HAST + ZFS) successfully, without kernel panics, without core dumps, without deadlocks, without issues, etc. I need to know I'm not chasing a dead rabbit. In tests using VirtualBox and FreeBSD 8-STABLE from when HAST was first MFC'd, everything worked wonderfully. HAST-based pool would come up, data would sync to the slave node, fail-over worked nicely, bringing the other box back online as the slave worked, data synced back, etc. It was a thing of beauty. Now, on real hardware, I cannot get the system to stay online for more than an hour. :( hastd causes kernel panics with "bufwrite: buffer not busy" errors. ZFS pools get corrupted. System deadlocks (no log messages, no onscreen errors, not even NumLock key works) at random points. The hardware is fairly standard fare: - SuperMicro H8DGi-F motherboard - AMD Opteron 6100-series CPU (8-cores @ 2.0 GHz) - 8 GB DDR3 SDRAM - 64 GB Kingston V-Series SSD for the OS install (using ahci(4) and the motherboard SATA controller) - 3x SuperMicro AOC-USAS2-8Li SATA controllers with IT firmware - 6x 1.5 TB Seagate 7200.11 drives (1x raidz2 vdev) - 12x 1.0 TB Seagate 7200.12 drives (2x raidz2 vdev) - 6x 0.5 TB WD RE3 drives (1x raidz2 vdev) The motherboard BIOS is up-to-date. I do not see any way to update the firmware on the SATA controllers. Using the onboard IPMI-based sensors, CPU, motherboard, RAM temps and volatages are in the nominal range. I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28 patches, and 9-CURRENT (after the ZFSv28 commit). Things work well until I start hastd. Then either the system locks up, or hastd causes a kernel panic, or hastd dumps core. Each harddrive is glabel'd as "disk-a1" through "disk-d6". hast.conf has 24 resources listed, one for each glabel'd device. The pool is created using the /dev/hast/* devices with disk-a1 through disk-a6 being one raidz2 vdev, and so on through disk-b*, disk-c*, and disk-d*, for a total of 4 raidz2 vdevs of 6 drives each. A fairly standard setup, I would think. Even using a GENERIC kernel, I can't keep things stable and running. So, please, someone, somewhere, share a success story, where you're using FreeBSD, ZFS, and HAST. Let me know that it does work. I'm starting to lose faith in my abilities here. :( Or point out where I'm doing things wrong so I can correct the issues. Thanks. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Mar 24 23:04:07 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7DCE1065678 for ; Thu, 24 Mar 2011 23:04:07 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2002:d596:2a92:2:155::]) by mx1.freebsd.org (Postfix) with ESMTP id A2FBF8FC17 for ; Thu, 24 Mar 2011 23:04:07 +0000 (UTC) Received: from tykburk.tyknet.cn.dom (unknown [IPv6:2002:5996:79d2:1:224:8cff:fe02:de01]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id A2B61638DAB; Fri, 25 Mar 2011 00:04:06 +0100 (CET) X-DKIM: OpenDKIM Filter v2.2.2 mail.tyknet.dk A2B61638DAB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1301007846; bh=fcB5PImYefJKrNtp6euVpO0NxDT+uoDbAAerrRiqPKY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=a8JJMs6p7P5kzBgeNj5PRacaevswnmK55svnfmgf9nmRm1Gjw5psXC3r15WwlFkcZ jhXtRe17H40LlccKfa8b2K7jYIUQaWJCqc4+ozVpJ40x+fywVFUwwoPkAGgC/NLG9I VDADakLtdFHZgODf1ndJBEP4ntLNVzWM/VSShOQ0= Message-ID: <4D8BCDE5.9090608@gibfest.dk> Date: Fri, 25 Mar 2011 00:04:05 +0100 From: Thomas Steen Rasmussen User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101231 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Freddie Cash References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 23:04:08 -0000 On 24.03.2011 21:36, Freddie Cash wrote: > So, please, someone, somewhere, share a success story, where you're > using FreeBSD, ZFS, and HAST. Let me know that it does work. I'm > starting to lose faith in my abilities here. :( > Hello, It does work, I am using it on real hardware (A couple of Dell r510s IIRC), although my pool only covers 8 drives. I will be able to share configs tomorrow, but it sounds like they are pretty similar to yours (although I use GPT labels). The servers are running 8.2-R amd64 but were born with 8.1-R. I haven't had any problems worth mentioning. The servers mail/DB servers, not heavily loaded. Good luck with it, I'm sure you'll find the problem/solution soon :) -- Best regards Thomas Steen Rasmussen From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 00:59:28 2011 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6938106564A for ; Fri, 25 Mar 2011 00:59:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 702058FC15 for ; Fri, 25 Mar 2011 00:59:27 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2P0xOsC074649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Mar 2011 02:59:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2P0xO34037096 for ; Fri, 25 Mar 2011 02:59:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2P0xOu4037095 for fs@freebsd.org; Fri, 25 Mar 2011 02:59:24 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Mar 2011 02:59:24 +0200 From: Kostik Belousov To: fs@freebsd.org Message-ID: <20110325005923.GI78089@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uLnwevNQM8S3VmeD" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: O_CLOEXEC X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 00:59:28 -0000 --uLnwevNQM8S3VmeD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, below is the implementation of O_CLOEXEC flag for open(2). I also handle the fhopen(2), since the man page states that fhopen(2) takes the same flags as open(2), and it is more logical to change code then man page. It is somewhat curious that SUSv4 did not specified O_CLOEXEC behaviour for posix_openpt(). I left it out, but it probably makes sense to allow O_CLOEXEC there ? The falloc() KPI is left as is because the function is often used in the kernel and probably in the third-party modules. fdallocf() takes additional flag argument to set close-on-exec before any other thread might see new file descriptor. diff --git a/lib/libc/sys/open.2 b/lib/libc/sys/open.2 index deca8bc..e0f5fff 100644 --- a/lib/libc/sys/open.2 +++ b/lib/libc/sys/open.2 @@ -28,7 +28,7 @@ .\" @(#)open.2 8.2 (Berkeley) 11/16/93 .\" $FreeBSD$ .\" -.Dd February 28, 2009 +.Dd March 25, 2011 .Dt OPEN 2 .Os .Sh NAME @@ -118,6 +118,7 @@ O_NOFOLLOW do not follow symlinks O_NOCTTY don't assign controlling terminal O_TTY_INIT restore default terminal attributes O_DIRECTORY error if file is not a directory +O_CLOEXEC set FD_CLOEXEC upon open .Ed .Pp Opening a file with @@ -231,6 +232,11 @@ from opening files which are even unsafe to open with .Dv O_RDONLY , such as device nodes. .Pp +.Dv O_CLOEXEC +may be used to set +.Dv FD_CLOEXEC +flag for the newly returned file descriptor. +.Pp If successful, .Fn open returns a non-negative integer, termed a file descriptor. @@ -241,12 +247,18 @@ file is set to the beginning of the file. When a new file is created it is given the group of the directory which contains it. .Pp -The new descriptor is set to remain open across +Unless +.Dv +O_CLOEXEC +flag was specified, +the new descriptor is set to remain open across .Xr execve 2 system calls; see -.Xr close 2 +.Xr close 2 , +.Xr fcntl 2 and -.Xr fcntl 2 . +.Dv O_CLOEXEC +description. .Pp The system imposes a limit on the number of file descriptors open simultaneously by one process. diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index a979368..21590d3 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -1516,7 +1516,7 @@ fdavail(struct thread *td, int n) * release the FILEDESC lock. */ int -falloc(struct thread *td, struct file **resultfp, int *resultfd) +fallocf(struct thread *td, struct file **resultfp, int *resultfd, int flag= s) { struct proc *p =3D td->td_proc; struct file *fp; @@ -1559,6 +1559,8 @@ falloc(struct thread *td, struct file **resultfp, int= *resultfd) return (error); } p->p_fd->fd_ofiles[i] =3D fp; + if ((flags & O_CLOEXEC) !=3D 0) + p->p_fd->fd_ofileflags[i] |=3D UF_EXCLOSE; FILEDESC_XUNLOCK(p->p_fd); if (resultfp) *resultfp =3D fp; @@ -1567,6 +1569,13 @@ falloc(struct thread *td, struct file **resultfp, in= t *resultfd) return (0); } =20 +int +falloc(struct thread *td, struct file **resultfp, int *resultfd) +{ + + return (fallocf(td, resultfp, resultfd, 0)); +} + /* * Build a new filedesc structure from another. * Copy the current, root, and jail root vnode references. diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index 9046d1c..fe66591 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -1069,7 +1069,7 @@ kern_openat(struct thread *td, int fd, char *path, en= um uio_seg pathseg, else flags =3D FFLAGS(flags); =20 - error =3D falloc(td, &nfp, &indx); + error =3D fallocf(td, &nfp, &indx, flags); if (error) return (error); /* An extra reference on `nfp' has been held for us by falloc(). */ @@ -4488,7 +4488,7 @@ fhopen(td, uap) * end of vn_open code */ =20 - if ((error =3D falloc(td, &nfp, &indx)) !=3D 0) { + if ((error =3D fallocf(td, &nfp, &indx, fmode)) !=3D 0) { if (fmode & FWRITE) vp->v_writecount--; goto bad; diff --git a/sys/sys/fcntl.h b/sys/sys/fcntl.h index ef394a3..6f6e348 100644 --- a/sys/sys/fcntl.h +++ b/sys/sys/fcntl.h @@ -123,9 +123,11 @@ typedef __pid_t pid_t; #define FEXEC O_EXEC #endif =20 -/* Defined by POSIX 1003.1-2008; BSD default, but reserve for future use. = */ #if __POSIX_VISIBLE >=3D 200809 +/* Defined by POSIX 1003.1-2008; BSD default, but reserve for future use. = */ #define O_TTY_INIT 0x00080000 /* Restore default termios attributes */ + +#define O_CLOEXEC 0x00100000 #endif =20 /* diff --git a/sys/sys/filedesc.h b/sys/sys/filedesc.h index dd97d44..c96d6f9 100644 --- a/sys/sys/filedesc.h +++ b/sys/sys/filedesc.h @@ -112,6 +112,8 @@ int closef(struct file *fp, struct thread *td); int dupfdopen(struct thread *td, struct filedesc *fdp, int indx, int dfd, int mode, int error); int falloc(struct thread *td, struct file **resultfp, int *resultfd); +int fallocf(struct thread *td, struct file **resultfp, int *resultfd, + int flags); int fdalloc(struct thread *td, int minfd, int *result); int fdavail(struct thread *td, int n); int fdcheckstd(struct thread *td); --uLnwevNQM8S3VmeD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2L6OsACgkQC3+MBN1Mb4gmzgCg3i18tgBApyAs8ZORfcJ209PY QckAoM6S26B80s5fHJTsMejzXlyLX/SY =hSgT -----END PGP SIGNATURE----- --uLnwevNQM8S3VmeD-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 07:47:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D11DB106566C; Fri, 25 Mar 2011 07:47:22 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (unknown [IPv6:2001:470:1f09:176e::3]) by mx1.freebsd.org (Postfix) with ESMTP id 805578FC17; Fri, 25 Mar 2011 07:47:22 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q31jm-000IDw-6t; Fri, 25 Mar 2011 07:47:14 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q31jm-0001st-5R; Fri, 25 Mar 2011 07:47:14 +0000 To: fjwcash@gmail.com, freebsd-current@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Fri, 25 Mar 2011 07:47:14 +0000 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 07:47:22 -0000 > So, please, someone, somewhere, share a success story, where you're > using FreeBSD, ZFS, and HAST. Let me know that it does work. I'm > starting to lose faith in my abilities here. :( I ran our main database for the old company using ZFS on top of HAST without any problems at all. Had a single HAST disc with a zpool on top of it, and mysql on top of that. All worked perfectly for us. Am not running that currently as the company went under and we lost the hardware. But am working for a new business and am about to deploy the same configuration for the main database as its "tried and tested" as far as I am concerned. Will be slightly different, as I will have a pair of HAST drives and do mirroring over the top with ZFS. But I shall report back how well, or not, it works. -pete. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 07:55:55 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3181B106564A; Fri, 25 Mar 2011 07:55:55 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id C1FDD8FC15; Fri, 25 Mar 2011 07:55:54 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id AC11445C9C; Fri, 25 Mar 2011 08:55:52 +0100 (CET) Received: from localhost (58.wheelsystems.com [83.12.187.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6FE7045684; Fri, 25 Mar 2011 08:55:47 +0100 (CET) Date: Fri, 25 Mar 2011 08:55:41 +0100 From: Pawel Jakub Dawidek To: Freddie Cash Message-ID: <20110325075541.GA1742@garage.freebsd.pl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-3.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, RCVD_IN_SORBS_DUL autolearn=ham version=3.0.4 Cc: FreeBSD Filesystems , FreeBSD-Current , FreeBSD Stable Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 07:55:55 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: > I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28 > patches, and 9-CURRENT (after the ZFSv28 commit). Things work well > until I start hastd. Then either the system locks up, or hastd causes > a kernel panic, or hastd dumps core. The minimum amount of information (as always) would be backtrace from the kernel and also hastd backtrace when it coredumps. There is really decent logging in hast, so I'm also sure it does log something interesting on primary or secondary. Another useful thing would be to turn on debugging in hast (single -d option for hastd). The best you can do is to give me the simplest and quickest procedure to reproduce the issue, eg. configure two hast resources, put ZFS mirror on top, start rsync /usr/src to the file system on top of hast and switch roles. The simpler the better. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk2MSn0ACgkQForvXbEpPzTz3QCgkK7c/o/yMaEma5RD8bgi7dfJ 3RgAnjEplmywJp8+ozatEd4eYu4Ce+Ds =iZuF -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 12:25:12 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6404E1065678 for ; Fri, 25 Mar 2011 12:25:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3BBFD8FC14 for ; Fri, 25 Mar 2011 12:25:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id CAFFA46B09; Fri, 25 Mar 2011 08:25:11 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C9ED8A01B; Fri, 25 Mar 2011 08:25:11 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Fri, 25 Mar 2011 08:14:47 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <20110325005923.GI78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110325005923.GI78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103250814.47903.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 25 Mar 2011 08:25:11 -0400 (EDT) Cc: Subject: Re: O_CLOEXEC X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 12:25:12 -0000 On Thursday, March 24, 2011 8:59:24 pm Kostik Belousov wrote: > Hi, > below is the implementation of O_CLOEXEC flag for open(2). I also > handle the fhopen(2), since the man page states that fhopen(2) takes > the same flags as open(2), and it is more logical to change code > then man page. > > It is somewhat curious that SUSv4 did not specified O_CLOEXEC behaviour > for posix_openpt(). I left it out, but it probably makes sense to > allow O_CLOEXEC there ? > > The falloc() KPI is left as is because the function is often used > in the kernel and probably in the third-party modules. fdallocf() > takes additional flag argument to set close-on-exec before any other > thread might see new file descriptor. Hmm, I don't actually expect falloc() to be used in 3rd party modules and would be fine with just adding a new flags parameter to it. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 12:34:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70022106567B; Fri, 25 Mar 2011 12:34:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C47468FC19; Fri, 25 Mar 2011 12:34:26 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2PCYMmE049383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 14:34:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2PCYMmR041413; Fri, 25 Mar 2011 14:34:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2PCYM38041412; Fri, 25 Mar 2011 14:34:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Mar 2011 14:34:22 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110325123422.GK78089@deviant.kiev.zoral.com.ua> References: <20110325005923.GI78089@deviant.kiev.zoral.com.ua> <201103250814.47903.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Dj2YR7i9IjIuF3W" Content-Disposition: inline In-Reply-To: <201103250814.47903.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: O_CLOEXEC X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 12:34:27 -0000 --1Dj2YR7i9IjIuF3W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 08:14:47AM -0400, John Baldwin wrote: > On Thursday, March 24, 2011 8:59:24 pm Kostik Belousov wrote: > > Hi, > > below is the implementation of O_CLOEXEC flag for open(2). I also > > handle the fhopen(2), since the man page states that fhopen(2) takes > > the same flags as open(2), and it is more logical to change code > > then man page. > >=20 > > It is somewhat curious that SUSv4 did not specified O_CLOEXEC behaviour > > for posix_openpt(). I left it out, but it probably makes sense to > > allow O_CLOEXEC there ? > >=20 > > The falloc() KPI is left as is because the function is often used > > in the kernel and probably in the third-party modules. fdallocf() > > takes additional flag argument to set close-on-exec before any other > > thread might see new file descriptor. >=20 > Hmm, I don't actually expect falloc() to be used in 3rd party modules and= =20 > would be fine with just adding a new flags parameter to it. The calls to falloc() appear in such modules as cryptodev(4). I do not mind changing falloc interface, but I also intend to merge O_CLOEXEC to stable/8. Are you fine with merging your suggestion to stable branch, while falloc() is called from cryptodev, zlib, linux (later is not a big issue if I bump __FreeBSD_version) ? --1Dj2YR7i9IjIuF3W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2Mi80ACgkQC3+MBN1Mb4gHIACfRPFmuiXAcZZopBtLG5yJIaLS zGAAn0oG3gmcpbPkQHH1unLp0R6bjpba =f6IE -----END PGP SIGNATURE----- --1Dj2YR7i9IjIuF3W-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 13:36:58 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D48C1065673 for ; Fri, 25 Mar 2011 13:36:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 02E9C8FC14 for ; Fri, 25 Mar 2011 13:36:58 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7718B46B32; Fri, 25 Mar 2011 09:36:57 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 069AF8A01B; Fri, 25 Mar 2011 09:36:57 -0400 (EDT) From: John Baldwin To: Kostik Belousov Date: Fri, 25 Mar 2011 09:36:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <20110325005923.GI78089@deviant.kiev.zoral.com.ua> <201103250814.47903.jhb@freebsd.org> <20110325123422.GK78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110325123422.GK78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201103250936.56512.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 25 Mar 2011 09:36:57 -0400 (EDT) Cc: freebsd-fs@freebsd.org Subject: Re: O_CLOEXEC X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 13:36:58 -0000 On Friday, March 25, 2011 8:34:22 am Kostik Belousov wrote: > On Fri, Mar 25, 2011 at 08:14:47AM -0400, John Baldwin wrote: > > On Thursday, March 24, 2011 8:59:24 pm Kostik Belousov wrote: > > > Hi, > > > below is the implementation of O_CLOEXEC flag for open(2). I also > > > handle the fhopen(2), since the man page states that fhopen(2) takes > > > the same flags as open(2), and it is more logical to change code > > > then man page. > > > > > > It is somewhat curious that SUSv4 did not specified O_CLOEXEC behaviour > > > for posix_openpt(). I left it out, but it probably makes sense to > > > allow O_CLOEXEC there ? > > > > > > The falloc() KPI is left as is because the function is often used > > > in the kernel and probably in the third-party modules. fdallocf() > > > takes additional flag argument to set close-on-exec before any other > > > thread might see new file descriptor. > > > > Hmm, I don't actually expect falloc() to be used in 3rd party modules and > > would be fine with just adding a new flags parameter to it. > > The calls to falloc() appear in such modules as cryptodev(4). > I do not mind changing falloc interface, but I also intend to merge > O_CLOEXEC to stable/8. Are you fine with merging your suggestion to > stable branch, while falloc() is called from cryptodev, zlib, > linux (later is not a big issue if I bump __FreeBSD_version) ? Hmmm, there are a few ways, but perhaps the simplest is to commit the current approach (and MFC it), but to do a followup commit to HEAD to remove fallocf() and add the flags argument to falloc(). That changes the KPI for 9+, but avoids growing the future KPI. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 13:43:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 470A6106566B; Fri, 25 Mar 2011 13:43:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BF6C78FC1D; Fri, 25 Mar 2011 13:43:05 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2PDh1Gd055599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 15:43:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2PDh1eO041844; Fri, 25 Mar 2011 15:43:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2PDh1HG041843; Fri, 25 Mar 2011 15:43:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Mar 2011 15:43:01 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110325134301.GM78089@deviant.kiev.zoral.com.ua> References: <20110325005923.GI78089@deviant.kiev.zoral.com.ua> <201103250814.47903.jhb@freebsd.org> <20110325123422.GK78089@deviant.kiev.zoral.com.ua> <201103250936.56512.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3azwYLLVmtMtZFH5" Content-Disposition: inline In-Reply-To: <201103250936.56512.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: O_CLOEXEC X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 13:43:06 -0000 --3azwYLLVmtMtZFH5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 09:36:56AM -0400, John Baldwin wrote: > On Friday, March 25, 2011 8:34:22 am Kostik Belousov wrote: > > On Fri, Mar 25, 2011 at 08:14:47AM -0400, John Baldwin wrote: > > > On Thursday, March 24, 2011 8:59:24 pm Kostik Belousov wrote: > > > > Hi, > > > > below is the implementation of O_CLOEXEC flag for open(2). I also > > > > handle the fhopen(2), since the man page states that fhopen(2) takes > > > > the same flags as open(2), and it is more logical to change code > > > > then man page. > > > >=20 > > > > It is somewhat curious that SUSv4 did not specified O_CLOEXEC behav= iour > > > > for posix_openpt(). I left it out, but it probably makes sense to > > > > allow O_CLOEXEC there ? > > > >=20 > > > > The falloc() KPI is left as is because the function is often used > > > > in the kernel and probably in the third-party modules. fdallocf() > > > > takes additional flag argument to set close-on-exec before any other > > > > thread might see new file descriptor. > > >=20 > > > Hmm, I don't actually expect falloc() to be used in 3rd party modules= and=20 > > > would be fine with just adding a new flags parameter to it. > >=20 > > The calls to falloc() appear in such modules as cryptodev(4). > > I do not mind changing falloc interface, but I also intend to merge > > O_CLOEXEC to stable/8. Are you fine with merging your suggestion to > > stable branch, while falloc() is called from cryptodev, zlib, > > linux (later is not a big issue if I bump __FreeBSD_version) ? >=20 > Hmmm, there are a few ways, but perhaps the simplest is to commit the > current approach (and MFC it), but to do a followup commit to HEAD to > remove fallocf() and add the flags argument to falloc(). That changes > the KPI for 9+, but avoids growing the future KPI. I will do this, thanks. --3azwYLLVmtMtZFH5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2Mm+UACgkQC3+MBN1Mb4iSxgCfWL/xnze3fi8GDtAjYrji7GXD vg0AniEHyvVJVlGL7WOEL2jG3JCe8mo6 =zP3o -----END PGP SIGNATURE----- --3azwYLLVmtMtZFH5-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 14:56:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D9061065670; Fri, 25 Mar 2011 14:56:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4C08FC0C; Fri, 25 Mar 2011 14:56:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2PEuEPt061172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 16:56:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2PEuEBV042415; Fri, 25 Mar 2011 16:56:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2PEuEVE042414; Fri, 25 Mar 2011 16:56:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Mar 2011 16:56:14 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110325145614.GN78089@deviant.kiev.zoral.com.ua> References: <20110325005923.GI78089@deviant.kiev.zoral.com.ua> <201103250814.47903.jhb@freebsd.org> <20110325123422.GK78089@deviant.kiev.zoral.com.ua> <201103250936.56512.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TBIaq1yoUA4huN1+" Content-Disposition: inline In-Reply-To: <201103250936.56512.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: O_CLOEXEC X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 14:56:20 -0000 --TBIaq1yoUA4huN1+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 09:36:56AM -0400, John Baldwin wrote: > On Friday, March 25, 2011 8:34:22 am Kostik Belousov wrote: > > On Fri, Mar 25, 2011 at 08:14:47AM -0400, John Baldwin wrote: > > > On Thursday, March 24, 2011 8:59:24 pm Kostik Belousov wrote: > > > > Hi, > > > > below is the implementation of O_CLOEXEC flag for open(2). I also > > > > handle the fhopen(2), since the man page states that fhopen(2) takes > > > > the same flags as open(2), and it is more logical to change code > > > > then man page. > > > >=20 > > > > It is somewhat curious that SUSv4 did not specified O_CLOEXEC behav= iour > > > > for posix_openpt(). I left it out, but it probably makes sense to > > > > allow O_CLOEXEC there ? > > > >=20 > > > > The falloc() KPI is left as is because the function is often used > > > > in the kernel and probably in the third-party modules. fdallocf() > > > > takes additional flag argument to set close-on-exec before any other > > > > thread might see new file descriptor. > > >=20 > > > Hmm, I don't actually expect falloc() to be used in 3rd party modules= and=20 > > > would be fine with just adding a new flags parameter to it. > >=20 > > The calls to falloc() appear in such modules as cryptodev(4). > > I do not mind changing falloc interface, but I also intend to merge > > O_CLOEXEC to stable/8. Are you fine with merging your suggestion to > > stable branch, while falloc() is called from cryptodev, zlib, > > linux (later is not a big issue if I bump __FreeBSD_version) ? >=20 > Hmmm, there are a few ways, but perhaps the simplest is to commit the > current approach (and MFC it), but to do a followup commit to HEAD to > remove fallocf() and add the flags argument to falloc(). That changes > the KPI for 9+, but avoids growing the future KPI. I will commit the change below after r219999 is merged to 8. diff --git a/sys/dev/streams/streams.c b/sys/dev/streams/streams.c index 7b99d20..00f65a3 100644 --- a/sys/dev/streams/streams.c +++ b/sys/dev/streams/streams.c @@ -241,7 +241,7 @@ streamsopen(struct cdev *dev, int oflags, int devtype, = struct thread *td) } =20 fdp =3D td->td_proc->p_fd; - if ((error =3D falloc(td, &fp, &fd)) !=3D 0) + if ((error =3D falloc(td, &fp, &fd, 0)) !=3D 0) return error; /* An extra reference on `fp' has been held for us by falloc(). */ =20 diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c index 21590d3..b69460a 100644 --- a/sys/kern/kern_descrip.c +++ b/sys/kern/kern_descrip.c @@ -1516,7 +1516,7 @@ fdavail(struct thread *td, int n) * release the FILEDESC lock. */ int -fallocf(struct thread *td, struct file **resultfp, int *resultfd, int flag= s) +falloc(struct thread *td, struct file **resultfp, int *resultfd, int flags) { struct proc *p =3D td->td_proc; struct file *fp; @@ -1569,13 +1569,6 @@ fallocf(struct thread *td, struct file **resultfp, i= nt *resultfd, int flags) return (0); } =20 -int -falloc(struct thread *td, struct file **resultfp, int *resultfd) -{ - - return (fallocf(td, resultfp, resultfd, 0)); -} - /* * Build a new filedesc structure from another. * Copy the current, root, and jail root vnode references. diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c index 5df669d..e14ae02 100644 --- a/sys/kern/kern_event.c +++ b/sys/kern/kern_event.c @@ -684,7 +684,7 @@ kqueue(struct thread *td, struct kqueue_args *uap) int fd, error; =20 fdp =3D td->td_proc->p_fd; - error =3D falloc(td, &fp, &fd); + error =3D falloc(td, &fp, &fd, 0); if (error) goto done2; =20 diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c index d3929b4..50b0389 100644 --- a/sys/kern/sys_pipe.c +++ b/sys/kern/sys_pipe.c @@ -348,7 +348,7 @@ kern_pipe(struct thread *td, int fildes[2]) rpipe->pipe_state |=3D PIPE_DIRECTOK; wpipe->pipe_state |=3D PIPE_DIRECTOK; =20 - error =3D falloc(td, &rf, &fd); + error =3D falloc(td, &rf, &fd, 0); if (error) { pipeclose(rpipe); pipeclose(wpipe); @@ -364,7 +364,7 @@ kern_pipe(struct thread *td, int fildes[2]) * side while we are blocked trying to allocate the write side. */ finit(rf, FREAD | FWRITE, DTYPE_PIPE, rpipe, &pipeops); - error =3D falloc(td, &wf, &fd); + error =3D falloc(td, &wf, &fd, 0); if (error) { fdclose(fdp, rf, fildes[0], td); fdrop(rf, td); diff --git a/sys/kern/tty_pts.c b/sys/kern/tty_pts.c index afbef1f..b749f3f 100644 --- a/sys/kern/tty_pts.c +++ b/sys/kern/tty_pts.c @@ -805,7 +805,7 @@ posix_openpt(struct thread *td, struct posix_openpt_arg= s *uap) if (uap->flags & ~(O_RDWR|O_NOCTTY)) return (EINVAL); =09 - error =3D falloc(td, &fp, &fd); + error =3D falloc(td, &fp, &fd, 0); if (error) return (error); =20 diff --git a/sys/kern/uipc_mqueue.c b/sys/kern/uipc_mqueue.c index f757cc5..9b334ac 100644 --- a/sys/kern/uipc_mqueue.c +++ b/sys/kern/uipc_mqueue.c @@ -1974,7 +1974,7 @@ kern_kmq_open(struct thread *td, const char *upath, i= nt flags, mode_t mode, if (len < 2 || path[0] !=3D '/' || index(path + 1, '/') !=3D NULL) return (EINVAL); =20 - error =3D falloc(td, &fp, &fd); + error =3D falloc(td, &fp, &fd, 0); if (error) return (error); =20 diff --git a/sys/kern/uipc_sem.c b/sys/kern/uipc_sem.c index 6ade212..917c343 100644 --- a/sys/kern/uipc_sem.c +++ b/sys/kern/uipc_sem.c @@ -422,7 +422,7 @@ ksem_create(struct thread *td, const char *name, semid_= t *semidp, mode_t mode, =20 fdp =3D td->td_proc->p_fd; mode =3D (mode & ~fdp->fd_cmask) & ACCESSPERMS; - error =3D falloc(td, &fp, &fd); + error =3D falloc(td, &fp, &fd, 0); if (error) { if (name =3D=3D NULL) error =3D ENOSPC; diff --git a/sys/kern/uipc_shm.c b/sys/kern/uipc_shm.c index cef8317..00496af 100644 --- a/sys/kern/uipc_shm.c +++ b/sys/kern/uipc_shm.c @@ -496,7 +496,7 @@ shm_open(struct thread *td, struct shm_open_args *uap) fdp =3D td->td_proc->p_fd; cmode =3D (uap->mode & ~fdp->fd_cmask) & ACCESSPERMS; =20 - error =3D falloc(td, &fp, &fd); + error =3D falloc(td, &fp, &fd, 0); if (error) return (error); =20 diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c index d3326d4..a4bbdba 100644 --- a/sys/kern/uipc_syscalls.c +++ b/sys/kern/uipc_syscalls.c @@ -176,7 +176,7 @@ socket(td, uap) return (error); #endif fdp =3D td->td_proc->p_fd; - error =3D falloc(td, &fp, &fd); + error =3D falloc(td, &fp, &fd, 0); if (error) return (error); /* An extra reference on `fp' has been held for us by falloc(). */ @@ -358,7 +358,7 @@ kern_accept(struct thread *td, int s, struct sockaddr *= *name, if (error !=3D 0) goto done; #endif - error =3D falloc(td, &nfp, &fd); + error =3D falloc(td, &nfp, &fd, 0); if (error) goto done; ACCEPT_LOCK(); @@ -606,12 +606,12 @@ kern_socketpair(struct thread *td, int domain, int ty= pe, int protocol, if (error) goto free1; /* On success extra reference to `fp1' and 'fp2' is set by falloc. */ - error =3D falloc(td, &fp1, &fd); + error =3D falloc(td, &fp1, &fd, 0); if (error) goto free2; rsv[0] =3D fd; fp1->f_data =3D so1; /* so1 already has ref count */ - error =3D falloc(td, &fp2, &fd); + error =3D falloc(td, &fp2, &fd, 0); if (error) goto free3; fp2->f_data =3D so2; /* so2 already has ref count */ @@ -2299,7 +2299,7 @@ sctp_peeloff(td, uap) * but that is ok. */ =20 - error =3D falloc(td, &nfp, &fd); + error =3D falloc(td, &nfp, &fd, 0); if (error) goto done; td->td_retval[0] =3D fd; diff --git a/sys/kern/vfs_syscalls.c b/sys/kern/vfs_syscalls.c index fe66591..dc1e262 100644 --- a/sys/kern/vfs_syscalls.c +++ b/sys/kern/vfs_syscalls.c @@ -1069,7 +1069,7 @@ kern_openat(struct thread *td, int fd, char *path, en= um uio_seg pathseg, else flags =3D FFLAGS(flags); =20 - error =3D fallocf(td, &nfp, &indx, flags); + error =3D falloc(td, &nfp, &indx, flags); if (error) return (error); /* An extra reference on `nfp' has been held for us by falloc(). */ @@ -4488,7 +4488,7 @@ fhopen(td, uap) * end of vn_open code */ =20 - if ((error =3D fallocf(td, &nfp, &indx, fmode)) !=3D 0) { + if ((error =3D falloc(td, &nfp, &indx, fmode)) !=3D 0) { if (fmode & FWRITE) vp->v_writecount--; goto bad; diff --git a/sys/opencrypto/cryptodev.c b/sys/opencrypto/cryptodev.c index 6a10f9a..2c0c503 100644 --- a/sys/opencrypto/cryptodev.c +++ b/sys/opencrypto/cryptodev.c @@ -1109,7 +1109,7 @@ cryptoioctl(struct cdev *dev, u_long cmd, caddr_t dat= a, int flag, struct thread TAILQ_INIT(&fcr->csessions); fcr->sesn =3D 0; =20 - error =3D falloc(td, &f, &fd); + error =3D falloc(td, &f, &fd, 0); =20 if (error) { free(fcr, M_XDATA); diff --git a/sys/sys/filedesc.h b/sys/sys/filedesc.h index c96d6f9..33dddca 100644 --- a/sys/sys/filedesc.h +++ b/sys/sys/filedesc.h @@ -111,8 +111,7 @@ struct thread; int closef(struct file *fp, struct thread *td); int dupfdopen(struct thread *td, struct filedesc *fdp, int indx, int dfd, int mode, int error); -int falloc(struct thread *td, struct file **resultfp, int *resultfd); -int fallocf(struct thread *td, struct file **resultfp, int *resultfd, +int falloc(struct thread *td, struct file **resultfp, int *resultfd, int flags); int fdalloc(struct thread *td, int minfd, int *result); int fdavail(struct thread *td, int n); --TBIaq1yoUA4huN1+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2MrQ4ACgkQC3+MBN1Mb4hF4QCeMaR13gNAiSkbLLu2Kiu17XdN nR4AoOBpFoLNf5czWKfhLudum9dlmHIh =4FHm -----END PGP SIGNATURE----- --TBIaq1yoUA4huN1+-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 16:10:15 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C8521065670 for ; Fri, 25 Mar 2011 16:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 717D78FC0C for ; Fri, 25 Mar 2011 16:10:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2PGAF78063450 for ; Fri, 25 Mar 2011 16:10:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2PGAFOb063448; Fri, 25 Mar 2011 16:10:15 GMT (envelope-from gnats) Date: Fri, 25 Mar 2011 16:10:15 GMT Message-Id: <201103251610.p2PGAFOb063448@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Pedro F. Giffuni" Cc: Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Pedro F. Giffuni" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 16:10:15 -0000 The following reply was made to PR kern/152079; it has been noted by GNATS. From: "Pedro F. Giffuni" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD Date: Fri, 25 Mar 2011 09:09:04 -0700 (PDT) --0-691748129-1301069344=:71034 Content-Type: text/plain; charset=us-ascii Include a small fix from NetBSD: msdosfs_vnops.c Revision 1.73: Remove a vnode reference leak from msdosfs_rename. Release tdvp if either doscheckpath() or relookup() fails. Adjust test fs/vfs/t_vnops.c and remove the link count test for msdos. Fixes NetBSD PR #44661 --0-691748129-1301069344=:71034 Content-Type: text/plain; name="patch-msdosfs.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-msdosfs.txt" ZGlmZiAtcnUgbXNkb3Nmcy5vcmlnL2Rlbm9kZS5oIG1zZG9zZnMvZGVub2Rl LmgKLS0tIG1zZG9zZnMub3JpZy9kZW5vZGUuaAkyMDExLTAzLTI1IDEwOjM0 OjQxLjAwMDAwMDAwMCArMDAwMAorKysgbXNkb3Nmcy9kZW5vZGUuaAkyMDEx LTAzLTI1IDEwOjM3OjA3LjAwMDAwMDAwMCArMDAwMApAQCAtNDcsNiArNDcs OCBAQAogICoKICAqIE9jdG9iZXIgMTk5MgogICovCisjaWZuZGVmIF9GU19N U0RPU0ZTX0RFTk9ERV9IXworI2RlZmluZSBfRlNfTVNET1NGU19ERU5PREVf SF8KIAogLyoKICAqIFRoaXMgaXMgdGhlIHBjIGZpbGVzeXN0ZW0gc3BlY2lm aWMgcG9ydGlvbiBvZiB0aGUgdm5vZGUgc3RydWN0dXJlLgpAQCAtMjA3LDgg KzIwOSw2IEBACiAJICAgICAoKGRlcCktPmRlX0F0dHJpYnV0ZXMgJiBBVFRS X0RJUkVDVE9SWSkgPyAwIDogKGRlcCktPmRlX0ZpbGVTaXplKSwgXAogCSBw dXR1c2hvcnQoKGRwKS0+ZGVIaWdoQ2x1c3QsIChkZXApLT5kZV9TdGFydENs dXN0ZXIgPj4gMTYpKQogCi0jaWZkZWYgX0tFUk5FTAotCiAjZGVmaW5lCVZU T0RFKHZwKQkoKHN0cnVjdCBkZW5vZGUgKikodnApLT52X2RhdGEpCiAjZGVm aW5lCURFVE9WKGRlKQkoKGRlKS0+ZGVfdm5vZGUpCiAKQEAgLTI1NCw2ICsy NTQsOCBAQAogI2VuZGlmCiB9OwogCisjaWZkZWYgX0tFUk5FTAorCiBleHRl cm4gc3RydWN0IHZvcF92ZWN0b3IgbXNkb3Nmc192bm9kZW9wczsKIAogaW50 IG1zZG9zZnNfbG9va3VwKHN0cnVjdCB2b3BfY2FjaGVkbG9va3VwX2FyZ3Mg Kik7CkBAIC0yNzksMyArMjgxLDQgQEAKIGludCBkZXRydW5jKHN0cnVjdCBk ZW5vZGUgKmRlcCwgdV9sb25nIGxlbmd0aCwgaW50IGZsYWdzLCBzdHJ1Y3Qg dWNyZWQgKmNyZWQsIHN0cnVjdCB0aHJlYWQgKnRkKTsKIGludCBkb3NjaGVj a3BhdGgoIHN0cnVjdCBkZW5vZGUgKnNvdXJjZSwgc3RydWN0IGRlbm9kZSAq dGFyZ2V0KTsKICNlbmRpZgkvKiBfS0VSTkVMICovCisjZW5kaWYgLyogIV9G U19NU0RPU0ZTX0RFTk9ERV9IXyAqLwpkaWZmIC1ydSBtc2Rvc2ZzLm9yaWcv bXNkb3Nmc19sb29rdXAuYyBtc2Rvc2ZzL21zZG9zZnNfbG9va3VwLmMKLS0t IG1zZG9zZnMub3JpZy9tc2Rvc2ZzX2xvb2t1cC5jCTIwMTEtMDMtMjUgMTA6 MzQ6NDEuMDAwMDAwMDAwICswMDAwCisrKyBtc2Rvc2ZzL21zZG9zZnNfbG9v a3VwLmMJMjAxMS0wMy0yNSAxMDozNzowNy4wMDAwMDAwMDAgKzAwMDAKQEAg LTQ1OCw3ICs0NTgsNyBAQAogCQkgKiBEb24ndCBhbGxvdyBkZWxldGluZyB0 aGUgcm9vdC4KIAkJICovCiAJCWlmIChibGtvZmYgPT0gTVNET1NGU1JPT1Rf T0ZTKQotCQkJcmV0dXJuIEVST0ZTOwkJCQkvKiByZWFsbHk/IFhYWCAqLwor CQkJcmV0dXJuIEVJTlZBTDsKIAogCQkvKgogCQkgKiBXcml0ZSBhY2Nlc3Mg dG8gZGlyZWN0b3J5IHJlcXVpcmVkIHRvIGRlbGV0ZSBmaWxlcy4KQEAgLTQ5 MSw3ICs0OTEsNyBAQAogCSAqLwogCWlmIChuYW1laW9wID09IFJFTkFNRSAm JiAoZmxhZ3MgJiBJU0xBU1RDTikpIHsKIAkJaWYgKGJsa29mZiA9PSBNU0RP U0ZTUk9PVF9PRlMpCi0JCQlyZXR1cm4gRVJPRlM7CQkJCS8qIHJlYWxseT8g WFhYICovCisJCQlyZXR1cm4gRUlOVkFMOwogCiAJCWVycm9yID0gVk9QX0FD Q0VTUyh2ZHAsIFZXUklURSwgY25wLT5jbl9jcmVkLCBjbnAtPmNuX3RocmVh ZCk7CiAJCWlmIChlcnJvcikKZGlmZiAtcnUgbXNkb3Nmcy5vcmlnL21zZG9z ZnNfdm5vcHMuYyBtc2Rvc2ZzL21zZG9zZnNfdm5vcHMuYwotLS0gbXNkb3Nm cy5vcmlnL21zZG9zZnNfdm5vcHMuYwkyMDExLTAzLTI1IDEwOjM0OjQxLjAw MDAwMDAwMCArMDAwMAorKysgbXNkb3Nmcy9tc2Rvc2ZzX3Zub3BzLmMJMjAx MS0wMy0yNSAxMTowMDo1NS4wMDAwMDAwMDAgKzAwMDAKQEAgLTEwOTQsMTIg KzEwOTQsMTIgQEAKIAkJICovCiAJCWVycm9yID0gZG9zY2hlY2twYXRoKGlw LCBkcCk7CiAJCWlmIChlcnJvcikKLQkJCWdvdG8gb3V0OworCQkJZ290byBi YWQ7CiAJCWlmICgodGNucC0+Y25fZmxhZ3MgJiBTQVZFU1RBUlQpID09IDAp CiAJCQlwYW5pYygibXNkb3Nmc19yZW5hbWU6IGxvc3QgdG8gc3RhcnRkaXIi KTsKIAkJZXJyb3IgPSByZWxvb2t1cCh0ZHZwLCAmdHZwLCB0Y25wKTsKIAkJ aWYgKGVycm9yKQotCQkJZ290byBvdXQ7CisJCQlnb3RvIGJhZDsKIAkJZHAg PSBWVE9ERSh0ZHZwKTsKIAkJeHAgPSB0dnAgPyBWVE9ERSh0dnApIDogTlVM TDsKIAl9CkBAIC0xMjgzLDcgKzEyODMsNiBAQAogCWlmICh4cCkKIAkJdnB1 dCh0dnApOwogCXZwdXQodGR2cCk7Ci1vdXQ6CiAJaXAtPmRlX2ZsYWcgJj0g fkRFX1JFTkFNRTsKIAl2cmVsZShmZHZwKTsKIAl2cmVsZShmdnApOwo= --0-691748129-1301069344=:71034-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 16:53:19 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3F11065672 for ; Fri, 25 Mar 2011 16:53:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9110C8FC12 for ; Fri, 25 Mar 2011 16:53:18 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2PGrEYr069328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 18:53:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2PGrEXW043050; Fri, 25 Mar 2011 18:53:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2PGrEZh043049; Fri, 25 Mar 2011 18:53:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Mar 2011 18:53:14 +0200 From: Kostik Belousov To: "Pedro F. Giffuni" Message-ID: <20110325165314.GO78089@deviant.kiev.zoral.com.ua> References: <201103251610.p2PGAFOb063448@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2phRCRr7PirLLhx" Content-Disposition: inline In-Reply-To: <201103251610.p2PGAFOb063448@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 16:53:19 -0000 --p2phRCRr7PirLLhx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 04:10:15PM +0000, Pedro F. Giffuni wrote: > The following reply was made to PR kern/152079; it has been noted by GNAT= S. >=20 > From: "Pedro F. Giffuni" > To: bug-followup@FreeBSD.org > Cc: =20 > Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other= NetBSD/OpenBSD > Date: Fri, 25 Mar 2011 09:09:04 -0700 (PDT) >=20 > --0-691748129-1301069344=3D:71034 > Content-Type: text/plain; charset=3Dus-ascii > =20 > Include a small fix from NetBSD: > =20 > msdosfs_vnops.c Revision 1.73: > Remove a vnode reference leak from msdosfs_rename. Release tdvp if either > doscheckpath() or relookup() fails. > =20 > Adjust test fs/vfs/t_vnops.c and remove the link count test for msdos. > =20 > Fixes NetBSD PR #44661 Can you extract the test referenced in the commit message ? I think that s/EROFS/EINVAL/ change could and should be committed first, and then the (potential) fix for the vnode leakage as a separate commit. --p2phRCRr7PirLLhx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2MyHoACgkQC3+MBN1Mb4gGQwCfSQKDH2YijpLy6YYC3o/ArYU/ 6ygAnjvoPU4c77LiJTYUx+3eKoWRNq1p =g0+4 -----END PGP SIGNATURE----- --p2phRCRr7PirLLhx-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 18:13:40 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D599D106566C for ; Fri, 25 Mar 2011 18:13:40 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by mx1.freebsd.org (Postfix) with SMTP id 95EFD8FC19 for ; Fri, 25 Mar 2011 18:13:40 +0000 (UTC) Received: from [98.139.91.68] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 25 Mar 2011 18:13:40 -0000 Received: from [98.139.91.7] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 25 Mar 2011 18:13:40 -0000 Received: from [127.0.0.1] by omp1007.mail.sp2.yahoo.com with NNFMP; 25 Mar 2011 18:13:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 256519.6971.bm@omp1007.mail.sp2.yahoo.com Received: (qmail 92667 invoked by uid 60001); 25 Mar 2011 18:13:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301076819; bh=4ReYo6JFQmTn39wDK7tnjF+Xkkn8tQ3nF/W2YRU1ZQY=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kXNy5oZ4aM0FzJPqMym9VQjbJ8woSJosbso5Z9oHGnfmZ1XEC6nrTiQHzz9fO3JBYg2LYaIe2ZFKUGyO7kJCFqq3NWl1J8TrgXFrrkPruYRFpCgLLNsDj4Yx0HHmPrm9NQwjf57nM6daPphkBGjrI0H++RyhfNPD3Cib2HOwmWk= Message-ID: <758552.89055.qm@web113514.mail.gq1.yahoo.com> X-YMail-OSG: FADhkkUVM1nZELD9pvl1XSnwo02c3Duq0uIiPToS2LR9Sd. 7PDOodttsY9nUpo5mUM7lx9mOS1HHAqyMYq6nhGWvpeu_2MvrJXA1xv_UoWR q28tIZ9YrQjRUoC1ZobcSPd2Y8NrFQNGS_odgnNijBZMgbgx1mBlLsG2EB3q Y0C0pd1H1jEragZUqIY0v5wga4uIKO76Mm5K8a7qEy9CrfZP9XTHyE7mBCNb IXvvJjD2GWqMqiENiGPc61.7FLkDxPurUsvcPpzqZcW4Df70r_hK7vyz_rZo HiCVqs2iaaGxNCJPFEL5C.a8S6d1ZpbDkDdKcScoPgcxqIyeKFUjW2C1Yfbv bzAqRxPP0gUx0ySC9ZPeTRA1g50EIvvqMNRelmL86tggXcxVjsH9aToihbV_ yy1Xh.e6Wy0nm Received: from [200.118.159.55] by web113514.mail.gq1.yahoo.com via HTTP; Fri, 25 Mar 2011 11:13:39 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Fri, 25 Mar 2011 11:13:39 -0700 (PDT) From: "Pedro F. Giffuni" To: Kostik Belousov In-Reply-To: <20110325165314.GO78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 18:13:40 -0000 Hello;=0A--- On Fri, 3/25/11, Kostik Belousov wrote:= =0A...=0A> >=A0 Fixes NetBSD PR #44661=0A> Can you extract the test referen= ced in the commit message=0A> ?=0AHere is the NetBSD link:=0A=0Ahttp://cvsw= eb.netbsd.org/bsdweb.cgi/src/tests/fs/vfs/t_vnops.c.diff?r1=3D1.21&r2=3D1.2= 2=0A=0Abut I have no idea if it will apply to our testing framework.=0A=0A>= =0A> I think that s/EROFS/EINVAL/ change could and should be=0A> committed= first, and then the (potential) fix for the=0A> vnode leakage as a separat= e commit.=0A>=0A=0AIt takes some time to get patches committed, so I usuall= y=0Aprefer to submit bigger patches, if I can, in order to save=0Areviewer'= s time.=0A=0AFWIW, I prefer so much bugzilla since permits better patch=0Ah= andling and obsoleting the diffs that have been applied=0Aalready. =0A=0A= =0A From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 20:57:00 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24326106566C for ; Fri, 25 Mar 2011 20:57:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 89F3A8FC15 for ; Fri, 25 Mar 2011 20:56:59 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2PKutdj087207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 22:56:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2PKusZC044052; Fri, 25 Mar 2011 22:56:54 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2PKus3C044051; Fri, 25 Mar 2011 22:56:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Mar 2011 22:56:54 +0200 From: Kostik Belousov To: "Pedro F. Giffuni" Message-ID: <20110325205654.GP78089@deviant.kiev.zoral.com.ua> References: <20110325165314.GO78089@deviant.kiev.zoral.com.ua> <758552.89055.qm@web113514.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fciAcgbhTOkUP7Ni" Content-Disposition: inline In-Reply-To: <758552.89055.qm@web113514.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 20:57:00 -0000 --fciAcgbhTOkUP7Ni Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 11:13:39AM -0700, Pedro F. Giffuni wrote: > Hello; > --- On Fri, 3/25/11, Kostik Belousov wrote: > ... > > >=9A Fixes NetBSD PR #44661 > > Can you extract the test referenced in the commit message > > ? > Here is the NetBSD link: >=20 > http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/fs/vfs/t_vnops.c.diff?r1=3D= 1.21&r2=3D1.22 >=20 > but I have no idea if it will apply to our testing framework. No, I do not want it in our testing framework. I want to see a standalone test that demonstrates the issue. I think the leak is real, but want to have a way to reproduce it before committing. The diff you pointed out to t_vnops.c does not make much sense to me. >=20 > >=20 > > I think that s/EROFS/EINVAL/ change could and should be > > committed first, and then the (potential) fix for the > > vnode leakage as a separate commit. > > >=20 > It takes some time to get patches committed, so I usually > prefer to submit bigger patches, if I can, in order to save > reviewer's time. EINVAL it trivial, and also it seems to be NOP, because VFS blocks attempts to delete or rename the mount point root directory. For delete, it is explicit check, for rename, the cause is the fact that lookup returns the covered vnode, and you either get a loop or cross-device link error. >=20 > FWIW, I prefer so much bugzilla since permits better patch > handling and obsoleting the diffs that have been applied > already.=20 >=20 >=20 > =20 --fciAcgbhTOkUP7Ni Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2NAZYACgkQC3+MBN1Mb4gecACdFAc9BUkPxpKKfovTecNgDh58 4KsAn1uDjuf/FpJYW2e7zkAD2gTL+s66 =pvy/ -----END PGP SIGNATURE----- --fciAcgbhTOkUP7Ni-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 25 22:40:14 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17F07106564A for ; Fri, 25 Mar 2011 22:40:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E1FAA8FC15 for ; Fri, 25 Mar 2011 22:40:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2PMeDYw015824 for ; Fri, 25 Mar 2011 22:40:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2PMeDU9015823; Fri, 25 Mar 2011 22:40:13 GMT (envelope-from gnats) Date: Fri, 25 Mar 2011 22:40:13 GMT Message-Id: <201103252240.p2PMeDU9015823@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/152079: commit references a PR X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 22:40:14 -0000 The following reply was made to PR kern/152079; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/152079: commit references a PR Date: Fri, 25 Mar 2011 22:31:42 +0000 (UTC) Author: kib Date: Fri Mar 25 22:31:28 2011 New Revision: 220014 URL: http://svn.freebsd.org/changeset/base/220014 Log: Report EBUSY instead of EROFS for attempt of deleting or renaming the root directory of msdosfs mount. The VFS code would handle deletion case itself too, assuming VV_ROOT flag is not lost. The msdosfs_rename() should also note attempt to rename root via doscheckpath() or different mount point check leading to EXDEV. Nonetheless, keep the checks for now. The change is inspired by NetBSD change referenced in PR, but return EBUSY like kern_unlinkat() does. PR: kern/152079 MFC after: 1 week Modified: head/sys/fs/msdosfs/msdosfs_lookup.c Modified: head/sys/fs/msdosfs/msdosfs_lookup.c ============================================================================== --- head/sys/fs/msdosfs/msdosfs_lookup.c Fri Mar 25 22:17:24 2011 (r220013) +++ head/sys/fs/msdosfs/msdosfs_lookup.c Fri Mar 25 22:31:28 2011 (r220014) @@ -458,7 +458,7 @@ foundroot: * Don't allow deleting the root. */ if (blkoff == MSDOSFSROOT_OFS) - return EROFS; /* really? XXX */ + return (EBUSY); /* * Write access to directory required to delete files. @@ -491,7 +491,7 @@ foundroot: */ if (nameiop == RENAME && (flags & ISLASTCN)) { if (blkoff == MSDOSFSROOT_OFS) - return EROFS; /* really? XXX */ + return (EBUSY); error = VOP_ACCESS(vdp, VWRITE, cnp->cn_cred, cnp->cn_thread); if (error) _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 00:21:56 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8734C1065673 for ; Sat, 26 Mar 2011 00:21:56 +0000 (UTC) (envelope-from freebsd@deman.com) Received: from plato.corp.nas.com (plato.corp.nas.com [66.114.32.138]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1718FC1A for ; Sat, 26 Mar 2011 00:21:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by plato.corp.nas.com (Postfix) with ESMTP id C58E2CA95E75 for ; Fri, 25 Mar 2011 17:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at corp.nas.com Received: from plato.corp.nas.com ([127.0.0.1]) by localhost (plato.corp.nas.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgJjCTKPqJyY for ; Fri, 25 Mar 2011 17:21:55 -0700 (PDT) Received: from [172.29.229.13] (gatekeeper2.sharplabs.com [216.65.151.102]) by plato.corp.nas.com (Postfix) with ESMTPSA id EC814CA95E69 for ; Fri, 25 Mar 2011 17:21:54 -0700 (PDT) From: Michael DeMan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Mar 2011 17:21:50 -0700 Message-Id: To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 00:21:56 -0000 Hi All, I seem to recall that there is a way to do this, but can no longer = google it. Basically, for NCQ support with SATA devices we are using the 'ada' = driver, which of course has SCSI like behavior. With two 8-port disk controllers in the system, we end up in the = uncomfortable situation where if the box is rebooted with an 'earlier' = drive in the list, the system boots up with different drives mapped to = adaX. This becomes more of a problem with multiple drive controllers = and not all the ports populated with drives at the start (i.e, add more = drives later). In our case, we have two Marvell controllers, and are doing ZFS = mirroring with drives off each controller. We end up with mvsch.0 through mvsch.15 showing up (16 controller = interfaces), but with only 10 drives right now, we end up with ada0 = through ada9. If we lose a drive and reboot, then we end up with the = upper ones each being ada(X-1), etc. If we add more drives, the = situation becomes even more confusing. Is there a way to force at boot time a mapping from the mvsch interface = to the specific ada disk that the operating system sees? Pretty sure I = saw something about this last summer but can't seem to find it now. What we would like to have, with 10 disks, is them showing up as: ada0, ada1, ada2, ada3, ada4 ada8, ada9, ada10, ada11, ada12 If we add another pair of disks in the future, we would know where to = physically insert them for ada5 and ada13, etc. Some appropriate sysctl info below. Thanks, - mike # sysctl -a | grep kern.disks kern.disks: ada9 ada8 ada7 ada6 ada5 ada4 ada3 ada2 ada1 ada0 da0 # sysctl -a | grep mvs dev.mvs.0.%desc: Marvell 88SX6081 SATA controller dev.mvs.0.%driver: mvs dev.mvs.0.%location: slot=3D1 function=3D0 dev.mvs.0.%pnpinfo: vendor=3D0x11ab device=3D0x6081 subvendor=3D0x11ab = subdevice=3D0x11ab class=3D0x010000 dev.mvs.0.%parent: pci1 dev.mvs.1.%desc: Marvell 88SX6081 SATA controller dev.mvs.1.%driver: mvs dev.mvs.1.%location: slot=3D3 function=3D0 dev.mvs.1.%pnpinfo: vendor=3D0x11ab device=3D0x6081 subvendor=3D0x11ab = subdevice=3D0x11ab class=3D0x010000 dev.mvs.1.%parent: pci1 dev.mvsch.0.%desc: Marvell SATA channel dev.mvsch.0.%driver: mvsch dev.mvsch.0.%location: channel=3D0 dev.mvsch.0.%parent: mvs0 dev.mvsch.1.%desc: Marvell SATA channel dev.mvsch.1.%driver: mvsch dev.mvsch.1.%location: channel=3D1 dev.mvsch.1.%parent: mvs0 dev.mvsch.2.%desc: Marvell SATA channel dev.mvsch.2.%driver: mvsch dev.mvsch.2.%location: channel=3D2 dev.mvsch.2.%parent: mvs0 dev.mvsch.3.%desc: Marvell SATA channel dev.mvsch.3.%driver: mvsch dev.mvsch.3.%location: channel=3D3 dev.mvsch.3.%parent: mvs0 dev.mvsch.4.%desc: Marvell SATA channel dev.mvsch.4.%driver: mvsch dev.mvsch.4.%location: channel=3D4 dev.mvsch.4.%parent: mvs0 dev.mvsch.5.%desc: Marvell SATA channel dev.mvsch.5.%driver: mvsch dev.mvsch.5.%location: channel=3D5 dev.mvsch.5.%parent: mvs0 dev.mvsch.6.%desc: Marvell SATA channel dev.mvsch.6.%driver: mvsch dev.mvsch.6.%location: channel=3D6 dev.mvsch.6.%parent: mvs0 dev.mvsch.7.%desc: Marvell SATA channel dev.mvsch.7.%driver: mvsch dev.mvsch.7.%location: channel=3D7 dev.mvsch.7.%parent: mvs0 dev.mvsch.8.%desc: Marvell SATA channel dev.mvsch.8.%driver: mvsch dev.mvsch.8.%location: channel=3D0 dev.mvsch.8.%parent: mvs1 dev.mvsch.9.%desc: Marvell SATA channel dev.mvsch.9.%driver: mvsch dev.mvsch.9.%location: channel=3D1 dev.mvsch.9.%parent: mvs1 dev.mvsch.10.%desc: Marvell SATA channel dev.mvsch.10.%driver: mvsch dev.mvsch.10.%location: channel=3D2 dev.mvsch.10.%parent: mvs1 dev.mvsch.11.%desc: Marvell SATA channel dev.mvsch.11.%driver: mvsch dev.mvsch.11.%location: channel=3D3 dev.mvsch.11.%parent: mvs1 dev.mvsch.12.%desc: Marvell SATA channel dev.mvsch.12.%driver: mvsch dev.mvsch.12.%location: channel=3D4 dev.mvsch.12.%parent: mvs1 dev.mvsch.13.%desc: Marvell SATA channel dev.mvsch.13.%driver: mvsch dev.mvsch.13.%location: channel=3D5 dev.mvsch.13.%parent: mvs1 dev.mvsch.14.%desc: Marvell SATA channel dev.mvsch.14.%driver: mvsch dev.mvsch.14.%location: channel=3D6 dev.mvsch.14.%parent: mvs1 dev.mvsch.15.%desc: Marvell SATA channel dev.mvsch.15.%driver: mvsch dev.mvsch.15.%location: channel=3D7 dev.mvsch.15.%parent: mvs1 From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 00:36:12 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D66E9106566B for ; Sat, 26 Mar 2011 00:36:12 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B43E8FC1A for ; Sat, 26 Mar 2011 00:36:12 +0000 (UTC) Received: by fxm11 with SMTP id 11so1931264fxm.13 for ; Fri, 25 Mar 2011 17:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3/BKnswF0w4TILtWUDGoKpMwq8X4NB3E43BShtPuw7o=; b=PFNe+0i0PmJ5oPK0QgrQ8J9R2xdY2cN7MPbdDiJzskd6zCt6uLdjiZJppSzQPeZrc7 Q0GzemZE91xFRm2u3MtaD1iHrpHTIS1oSR4I2sqbZtNrLDbQnhH5os3/E1oCvOOojP/F kclvsonY68fHwU471xZxJVv6z2S85SAVk8jsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XuVLMsCFGL5f3+H9c5JuIlBJptOK52/UGebaUT5fLxwcRgvNqH3kcYlllrO46D8hXE 6KMOxhi4RrEvMW2jLYEXbp9NB/HooTCuW/0F3QXFrqfDnm//+mu2JAJZNRzvSHCoVt1w mgU08idkI5OUeMo7x0EvT84lqpQHs1fu0WfUk= MIME-Version: 1.0 Received: by 10.223.127.210 with SMTP id h18mr1582295fas.79.1301099771385; Fri, 25 Mar 2011 17:36:11 -0700 (PDT) Received: by 10.223.101.208 with HTTP; Fri, 25 Mar 2011 17:36:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Mar 2011 19:36:11 -0500 Message-ID: From: Adam Vande More To: Michael DeMan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 00:36:12 -0000 On Fri, Mar 25, 2011 at 7:21 PM, Michael DeMan wrote: > Hi All, > > I seem to recall that there is a way to do this, but can no longer google > it. > > Is there a way to force at boot time a mapping from the mvsch interface to > the specific ada disk that the operating system sees? Pretty sure I saw > something about this last summer but can't seem to find it now. > Do you mean labeling disks? You can use either gpart(8) or glabe(8)l to accomplish this. If you're using GPT then gpart would probably be more preferable. -- Adam Vande More From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 00:38:29 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DE581065691 for ; Sat, 26 Mar 2011 00:38:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AF0328FC08 for ; Sat, 26 Mar 2011 00:38:27 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2Q0cIeF005879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 02:38:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2Q0cI8F045417; Sat, 26 Mar 2011 02:38:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2Q0cIZD045416; Sat, 26 Mar 2011 02:38:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 02:38:18 +0200 From: Kostik Belousov To: Michael DeMan Message-ID: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kkaprR7WznO6jOL+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 00:38:29 -0000 --kkaprR7WznO6jOL+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2011 at 05:21:50PM -0700, Michael DeMan wrote: > Hi All, >=20 > I seem to recall that there is a way to do this, but can no longer google= it. >=20 > Basically, for NCQ support with SATA devices we are using the 'ada' drive= r, which of course has SCSI like behavior. >=20 > With two 8-port disk controllers in the system, we end up in the uncomfor= table situation where if the box is rebooted with an 'earlier' drive in the= list, the system boots up with different drives mapped to adaX. This beco= mes more of a problem with multiple drive controllers and not all the ports= populated with drives at the start (i.e, add more drives later). >=20 > In our case, we have two Marvell controllers, and are doing ZFS mirroring= with drives off each controller. >=20 > We end up with mvsch.0 through mvsch.15 showing up (16 controller interfa= ces), but with only 10 drives right now, we end up with ada0 through ada9. = If we lose a drive and reboot, then we end up with the upper ones each bei= ng ada(X-1), etc. If we add more drives, the situation becomes even more c= onfusing. >=20 > Is there a way to force at boot time a mapping from the mvsch interface t= o the specific ada disk that the operating system sees? Pretty sure I saw = something about this last summer but can't seem to find it now. >=20 > What we would like to have, with 10 disks, is them showing up as: > ada0, ada1, ada2, ada3, ada4 > ada8, ada9, ada10, ada11, ada12 >=20 > If we add another pair of disks in the future, we would know where to phy= sically insert them for ada5 and ada13, etc. I use the following stanza in /boot/device.hints for machine with intel on-board ahci and siis in pcie: hint.scbus.0.at=3D"ahcich0" hint.ada.0.at=3D"scbus0" hint.scbus.1.at=3D"ahcich1" hint.ada.1.at=3D"scbus1" hint.scbus.2.at=3D"ahcich2" hint.ada.2.at=3D"scbus2" hint.scbus.3.at=3D"ahcich3" hint.ada.3.at=3D"scbus3" hint.scbus.4.at=3D"ahcich4" hint.ada.4.at=3D"scbus4" hint.scbus.5.at=3D"siisch0" hint.ada.5.at=3D"scbus5" hint.scbus.6.at=3D"siisch1" hint.ada.6.at=3D"scbus6" You should get an idea from this. --kkaprR7WznO6jOL+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2NNXkACgkQC3+MBN1Mb4ibPwCfQF2Al27cFvPCBM5UlGY2xIAJ f+gAoM/NiPYf7V98Al7ZitcQXLyqx8zt =Uc8v -----END PGP SIGNATURE----- --kkaprR7WznO6jOL+-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 01:01:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 817931065673 for ; Sat, 26 Mar 2011 01:01:41 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm5-vm1.bullet.mail.sp2.yahoo.com (nm5-vm1.bullet.mail.sp2.yahoo.com [98.139.91.205]) by mx1.freebsd.org (Postfix) with SMTP id 5D90A8FC22 for ; Sat, 26 Mar 2011 01:01:40 +0000 (UTC) Received: from [98.139.91.70] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 01:01:40 -0000 Received: from [98.139.91.60] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 01:01:40 -0000 Received: from [127.0.0.1] by omp1060.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 01:01:40 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 898931.70738.bm@omp1060.mail.sp2.yahoo.com Received: (qmail 97842 invoked by uid 60001); 26 Mar 2011 01:01:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301101299; bh=j/044l1Y7xedwX/bB2lfUh5/kcp4AU0tIOpeQ22umOU=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=l4cXPNswSQePRRTGU9mccHSy0BuMs4gAnpgGhA8wLVbYyEjs5j8uz7YKkBWRRSBagYHCFDOsef7ekqtYh0kMMreAwoU1X29UTTwoZJpzTJWD+kijGfItVo+GFk8bL5Qf1PqZsYg2RRCi1A4n9rn66NF1J+yhUo5Pua4wma0juG4= Message-ID: <650638.91967.qm@web113506.mail.gq1.yahoo.com> X-YMail-OSG: scMwYMwVM1kBgJHqc9VRQcT7M18ouhAYjd1Kc0lL.qf0wVf n.GpC.uQjPR2Y0vJeNEMhVBoxj21jnNUzYH7BD3uhVMrZARg_PxFmZ6xvo8N odMhAnJqs2arRLhsRJ9rjsAQDPh9EZ5dgRu_OR.mTqGrIQxpoVvnB6aYVFLL mpI3HK5fzJfxiQaCNobOW1T9.V4vGoXzkMfJZX8oqGV.kSqYwF_Sehbna8ty M2jEpL7aw6LPN_8CcOp.XHIpJ7sJOveDesroVETHTSMkrsxB6zdk4VvGIZKV HJ88AsN1igPanWhtSX5Deb3VpEzZBNIwdEVVa0HqGPQjkUgyxYk8.V.cOEfl Q6Aw6pZfhpBZOv3dLCkjgu.8RkSjyTaF8atH2_mRLiFJz6G35Z0D8Ocf0flq Q735JZoo3nQ_4 Received: from [200.118.159.55] by web113506.mail.gq1.yahoo.com via HTTP; Fri, 25 Mar 2011 18:01:39 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Fri, 25 Mar 2011 18:01:39 -0700 (PDT) From: "Pedro F. Giffuni" To: Kostik Belousov In-Reply-To: <20110325205654.GP78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 01:01:41 -0000 --- On Fri, 3/25/11, Kostik Belousov wrote: .... > No, I do not want it in our testing framework. I want to > see a standalone test that demonstrates the issue. > I think the leak is real, but want to have a way to > reproduce it before committing. > > The diff you pointed out to t_vnops.c does not make much > sense to me. I looked a little more in their records and I found this: _____ ... /* rename directory over an empty directory */ md(pb1, mp, "parent"); md(pb2, mp, "parent/dir1"); md(pb3, mp, "parent/dir2"); RL(rump_sys_mkdir(pb1, 0777)); RL(rump_sys_mkdir(pb2, 0777)); RL(rump_sys_mkdir(pb3, 0777)); RL(rump_sys_rename(pb2, pb3)); RL(rump_sys_stat(pb1, &sb)); ATF_CHECK_EQ(sb.st_nlink, 3); RL(rump_sys_rmdir(pb3)); if (FSTYPE_TMPFS(tc)) atf_tc_expect_signal(-1, "PR kern/44288"); ______ There's also this that was removed once the PR was fixed: - if (FSTYPE_MSDOS(tc)) - atf_tc_skip("test fails in some setups, reason unknown"); hope that helps. Pedro. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 02:02:51 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 946E5106564A for ; Sat, 26 Mar 2011 02:02:51 +0000 (UTC) (envelope-from freebsd@deman.com) Received: from cp11.openaccess.org (cp11.openaccess.org [66.114.41.130]) by mx1.freebsd.org (Postfix) with ESMTP id 710FE8FC0A for ; Sat, 26 Mar 2011 02:02:51 +0000 (UTC) Received: from c-67-170-191-30.hsd1.wa.comcast.net ([67.170.191.30] helo=[192.168.1.111]) by cp11.openaccess.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q3HoW-00025N-OU; Fri, 25 Mar 2011 17:57:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Michael DeMan In-Reply-To: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> Date: Fri, 25 Mar 2011 17:57:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp11.openaccess.org X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - deman.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 02:02:51 -0000 Yeah - this is what I was looking for. I can morph it for mvsch. In regards to prior post... The glabel solution works too, but again gets complicated when a regular = staff person just needs to swap out a drive, has the disk drive in hand = (which could either not have a glabel on it or maybe has one from = somewhere else by accident), and just needs to replace a drive. Thanks! - mike On Mar 25, 2011, at 5:38 PM, Kostik Belousov wrote: > On Fri, Mar 25, 2011 at 05:21:50PM -0700, Michael DeMan wrote: >> Hi All, >>=20 >> I seem to recall that there is a way to do this, but can no longer = google it. >>=20 >> Basically, for NCQ support with SATA devices we are using the 'ada' = driver, which of course has SCSI like behavior. >>=20 >> With two 8-port disk controllers in the system, we end up in the = uncomfortable situation where if the box is rebooted with an 'earlier' = drive in the list, the system boots up with different drives mapped to = adaX. This becomes more of a problem with multiple drive controllers = and not all the ports populated with drives at the start (i.e, add more = drives later). >>=20 >> In our case, we have two Marvell controllers, and are doing ZFS = mirroring with drives off each controller. >>=20 >> We end up with mvsch.0 through mvsch.15 showing up (16 controller = interfaces), but with only 10 drives right now, we end up with ada0 = through ada9. If we lose a drive and reboot, then we end up with the = upper ones each being ada(X-1), etc. If we add more drives, the = situation becomes even more confusing. >>=20 >> Is there a way to force at boot time a mapping from the mvsch = interface to the specific ada disk that the operating system sees? = Pretty sure I saw something about this last summer but can't seem to = find it now. >>=20 >> What we would like to have, with 10 disks, is them showing up as: >> ada0, ada1, ada2, ada3, ada4 >> ada8, ada9, ada10, ada11, ada12 >>=20 >> If we add another pair of disks in the future, we would know where to = physically insert them for ada5 and ada13, etc. >=20 > I use the following stanza in /boot/device.hints for machine with = intel > on-board ahci and siis in pcie: > hint.scbus.0.at=3D"ahcich0" > hint.ada.0.at=3D"scbus0" > hint.scbus.1.at=3D"ahcich1" > hint.ada.1.at=3D"scbus1" > hint.scbus.2.at=3D"ahcich2" > hint.ada.2.at=3D"scbus2" > hint.scbus.3.at=3D"ahcich3" > hint.ada.3.at=3D"scbus3" > hint.scbus.4.at=3D"ahcich4" > hint.ada.4.at=3D"scbus4" > hint.scbus.5.at=3D"siisch0" > hint.ada.5.at=3D"scbus5" > hint.scbus.6.at=3D"siisch1" > hint.ada.6.at=3D"scbus6" >=20 > You should get an idea from this. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 05:16:47 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 001871065670 for ; Sat, 26 Mar 2011 05:16:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC3B8FC19 for ; Sat, 26 Mar 2011 05:16:46 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id PhDY1g0031ap0As5ChGmB3; Sat, 26 Mar 2011 05:16:46 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.westchester.pa.mail.comcast.net with comcast id PhGl1g0081t3BNj3ihGl7o; Sat, 26 Mar 2011 05:16:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DE4259B429; Fri, 25 Mar 2011 22:16:43 -0700 (PDT) Date: Fri, 25 Mar 2011 22:16:43 -0700 From: Jeremy Chadwick To: Michael DeMan Message-ID: <20110326051643.GA43364@icarus.home.lan> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 05:16:47 -0000 On Fri, Mar 25, 2011 at 05:57:10PM -0700, Michael DeMan wrote: > Yeah - this is what I was looking for. I can morph it for mvsch. > > In regards to prior post... > The glabel solution works too, but again gets complicated when a regular staff person just needs to swap out a drive, has the disk drive in hand (which could either not have a glabel on it or maybe has one from somewhere else by accident), and just needs to replace a drive. > > Thanks! > > - mike > > On Mar 25, 2011, at 5:38 PM, Kostik Belousov wrote: > > > On Fri, Mar 25, 2011 at 05:21:50PM -0700, Michael DeMan wrote: > >> Hi All, > >> > >> I seem to recall that there is a way to do this, but can no longer google it. > >> > >> Basically, for NCQ support with SATA devices we are using the 'ada' driver, which of course has SCSI like behavior. > >> > >> With two 8-port disk controllers in the system, we end up in the uncomfortable situation where if the box is rebooted with an 'earlier' drive in the list, the system boots up with different drives mapped to adaX. This becomes more of a problem with multiple drive controllers and not all the ports populated with drives at the start (i.e, add more drives later). > >> > >> In our case, we have two Marvell controllers, and are doing ZFS mirroring with drives off each controller. > >> > >> We end up with mvsch.0 through mvsch.15 showing up (16 controller interfaces), but with only 10 drives right now, we end up with ada0 through ada9. If we lose a drive and reboot, then we end up with the upper ones each being ada(X-1), etc. If we add more drives, the situation becomes even more confusing. > >> > >> Is there a way to force at boot time a mapping from the mvsch interface to the specific ada disk that the operating system sees? Pretty sure I saw something about this last summer but can't seem to find it now. > >> > >> What we would like to have, with 10 disks, is them showing up as: > >> ada0, ada1, ada2, ada3, ada4 > >> ada8, ada9, ada10, ada11, ada12 > >> > >> If we add another pair of disks in the future, we would know where to physically insert them for ada5 and ada13, etc. > > > > I use the following stanza in /boot/device.hints for machine with intel > > on-board ahci and siis in pcie: > > hint.scbus.0.at="ahcich0" > > hint.ada.0.at="scbus0" > > hint.scbus.1.at="ahcich1" > > hint.ada.1.at="scbus1" > > hint.scbus.2.at="ahcich2" > > hint.ada.2.at="scbus2" > > hint.scbus.3.at="ahcich3" > > hint.ada.3.at="scbus3" > > hint.scbus.4.at="ahcich4" > > hint.ada.4.at="scbus4" > > hint.scbus.5.at="siisch0" > > hint.ada.5.at="scbus5" > > hint.scbus.6.at="siisch1" > > hint.ada.6.at="scbus6" > > > > You should get an idea from this. Why would the disk number change on a drive swap? This doesn't happen on my Intel ICH9R controller on *any* Supermicro X7xxx or Supermicro PDxxx board I have access to. The ONLY TIME I have seen this happen is in the following situation: 1) State: physical SATA port 0 <--> hot-swap backplane port 0 <--> disk ada0 physical SATA port 1 <--> hot-swap backplane port 1 <--> disk ada1 physical SATA port 2 <--> hot-swap backplane port 2 <--> empty physical SATA port 3 <--> hot-swap backplane port 3 <--> disk ada2 physical SATA port 4 <--> hot-swap backplane port 4 <--> disk ada3 physical SATA port 5 <--> hot-swap backplane port 5 <--> disk ada4 2) Administrator adds disk to backplane port 2. Disk appears as ada5. 3) Machine gets shut off, rebooted, whatever. 4) Kernel starts. State then becomes: physical SATA port 0 <--> hot-swap backplane port 0 <--> disk ada0 physical SATA port 1 <--> hot-swap backplane port 1 <--> disk ada1 physical SATA port 2 <--> hot-swap backplane port 2 <--> disk ada2 physical SATA port 3 <--> hot-swap backplane port 3 <--> disk ada3 physical SATA port 4 <--> hot-swap backplane port 4 <--> disk ada4 physical SATA port 5 <--> hot-swap backplane port 5 <--> disk ada5 I should note that in my experience (on multiple systems/boards/chassis) hot-swapping a disk *does not* change the disk number. E.g. yanking ada3 results in the SATA channel seeing a disconnection, and an insertion results in the SATA channel seeing an insertion of ada3. Two weeks ago I did this a good 15-16 times while I zeroed out all the old SATA disks I had laying around my flat. Anyway, the way I've addressed the problem described is: leave your empty disks at the "end of the SATA port chain" (I'm using the word chain incorrectly here; I am well aware SATA is 1:1 and not chained). If you *have* to move disks around/empty bays out which were previously filled, you should boot into single-user and fix things there before actually bringing up multi-user mode. I've mentioned this before -- and I'm certain others will point out that said problem was fixed, etc. etc. (done so before, and I've simply forgotten) -- but there are complexities introduced into the fray when using glabel(8) and similar utilities. There have been complaints on the lists about it. I've had a very, very long week and can't be bothered to dig up the evidence; sorry. This is one great thing about ZFS and disk tasting -- it doesn't matter if the disks all "shift up by one" (number-wise), it figures it out and does the Right Thing(tm) with pools as a result. This is why I tend to use ZFS on non-OS disks, that way if the above situation happens, I'm not fighting with the system after a disk replacement. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 06:15:58 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D982D106566B for ; Sat, 26 Mar 2011 06:15:58 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6238FC17 for ; Sat, 26 Mar 2011 06:15:58 +0000 (UTC) Received: by fxm11 with SMTP id 11so2051868fxm.13 for ; Fri, 25 Mar 2011 23:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jUWWBdP0q7GVgVsytjFjEURmmPRs251zkN/ZwpInwTk=; b=oJ6I28scxTv1IjU7zAnylxCuX1wgSlyX+/K4+K4mIJnv3pnDyJW2b/Yo60JRS9ratA tM4+QtvZQTNt2+1pX/WmGhfTfjZ0nDVtZcPpsp0Xgf2Y402IbXrj+9+3Umwi/1GKFqPV Y5g2fDyHeRsQxQNMQ84bUDj7LG65RpMOKkCSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oVI2+/y6XKL+zuthyNjaNpi7z7LrpByYlXbnhHerdYjSbI6ty0Mf4N09JpgLS/WxzS g0d9RJyhcZONJxOhqOTbVs1cscYj+C7GgVTLB++MDHOQ4RNIiIJhPKV1Ix4ZYAzvTAkh c6FUyn/rhHV+3VEB8Z1TV3Y8B9Z3pG672+JOQ= MIME-Version: 1.0 Received: by 10.223.120.1 with SMTP id b1mr1776269far.60.1301120157390; Fri, 25 Mar 2011 23:15:57 -0700 (PDT) Received: by 10.223.101.208 with HTTP; Fri, 25 Mar 2011 23:15:57 -0700 (PDT) In-Reply-To: <20110326051643.GA43364@icarus.home.lan> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> <20110326051643.GA43364@icarus.home.lan> Date: Sat, 26 Mar 2011 01:15:57 -0500 Message-ID: From: Adam Vande More To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 06:15:59 -0000 On Sat, Mar 26, 2011 at 12:16 AM, Jeremy Chadwick wrote: > I've mentioned this before -- and I'm certain others will point out that > said problem was fixed, etc. etc. (done so before, and I've simply > forgotten) -- but there are complexities introduced into the fray when > using glabel(8) and similar utilities. There have been complaints on > the lists about it. I've had a very, very long week and can't be > bothered to dig up the evidence; sorry. > FWIW, I believe you are referring to geom metatdata/GPT secondary table conflict. If you put a label on a GPT partition, it will overwrite it's backup GPT table. You'd want to do something like glabel the raw device,eg ada0 then create GPT partitions on the resulting device. This setup works fine, but is going to be a FreeBSD specific disk. Just using a GPT label on partition that spans the entire device may be more desirable depending on needs. -- Adam Vande More From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 08:09:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BECDA106566C for ; Sat, 26 Mar 2011 08:09:22 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E95B8FC16 for ; Sat, 26 Mar 2011 08:09:21 +0000 (UTC) Received: by fxm11 with SMTP id 11so2084370fxm.13 for ; Sat, 26 Mar 2011 01:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:x-comment-to :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=h6lVFVYyrVpiaXVEmcJKkkrm1VDzi659ORS0dvcqxTE=; b=X+tWseGdw/oMANxEI9JPsjXpr2WgNWCvDtr1aPteOUbq7jk+7pZ7B8VvnC1iJ3vLra byzV/RF/+Ni9Xl+F+4VONfeMfvFV+DBsxVxDBGlSxSpSd1I/tyuSEHTQIPHWw4RHvLA9 eZpCDHBJp3JdIsd2RtgPwMT/45jgi65TklO/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=mvw1AJhemux7m4NfW5da1HoE/pDBNRXeJyf6e/OmP3kD48+husoxpqFGB2zijwLKwY r8AEa9X75aiPBoBcxDHvQPg9wOfvItZWr4jLYk8KRFz6udGfQu6Zrl4rezXVBXF7wcqV pWvauA6nke9OIa2x4TJMhva98rKhFVOXJxgfo= Received: by 10.223.20.216 with SMTP id g24mr1909138fab.115.1301126961259; Sat, 26 Mar 2011 01:09:21 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id 14sm706456fae.47.2011.03.26.01.09.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 01:09:19 -0700 (PDT) From: Mikolaj Golub To: giffunip@tutopia.com References: <650638.91967.qm@web113506.mail.gq1.yahoo.com> X-Comment-To: Pedro F. Giffuni Sender: Mikolaj Golub Date: Sat, 26 Mar 2011 10:09:16 +0200 In-Reply-To: <650638.91967.qm@web113506.mail.gq1.yahoo.com> (Pedro F. Giffuni's message of "Fri, 25 Mar 2011 18:01:39 -0700 (PDT)") Message-ID: <86wrjmtiab.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 08:09:22 -0000 On Fri, 25 Mar 2011 18:01:39 -0700 (PDT) Pedro F. Giffuni wrote: PFG> --- On Fri, 3/25/11, Kostik Belousov wrote: PFG> .... >> No, I do not want it in our testing framework. I want to >> see a standalone test that demonstrates the issue. >> I think the leak is real, but want to have a way to >> reproduce it before committing. >> >> The diff you pointed out to t_vnops.c does not make much >> sense to me. PFG> I looked a little more in their records and I found this: PFG> _____ PFG> ... PFG> /* rename directory over an empty directory */ PFG> md(pb1, mp, "parent"); PFG> md(pb2, mp, "parent/dir1"); PFG> md(pb3, mp, "parent/dir2"); PFG> RL(rump_sys_mkdir(pb1, 0777)); PFG> RL(rump_sys_mkdir(pb2, 0777)); PFG> RL(rump_sys_mkdir(pb3, 0777)); PFG> RL(rump_sys_rename(pb2, pb3)); PFG> RL(rump_sys_stat(pb1, &sb)); PFG> ATF_CHECK_EQ(sb.st_nlink, 3); PFG> RL(rump_sys_rmdir(pb3)); PFG> if (FSTYPE_TMPFS(tc)) PFG> atf_tc_expect_signal(-1, "PR kern/44288"); PFG> ______ PFG> There's also this that was removed once the PR was fixed: PFG> - if (FSTYPE_MSDOS(tc)) PFG> - atf_tc_skip("test fails in some setups, reason unknown"); PFG> hope that helps. I suppose doing something like this on msdos fs: mkdir parent mkdir parent/1 mv parent/1 parent/2 ls -dl parent In the case of the leak we should see 4 in hard links number field instead of expected 3. But in FreeBSD it looks like msdosfs always reports link count 1: /dev/md1 on /mnt (msdosfs, local) [root@lolek ~]# cd /mnt/ [root@lolek /mnt]# mkdir parent [root@lolek /mnt]# mkdir parent/1 parent/2 parent/3 [root@lolek /mnt]# ls -ld parent drwxr-xr-x 1 root wheel 4096 Mar 26 11:56 parent Tested on 8-STABLE and CURRENT. -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 09:55:26 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0B9C1065670 for ; Sat, 26 Mar 2011 09:55:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5F5388FC15 for ; Sat, 26 Mar 2011 09:55:26 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2Q9sikV079602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 11:54:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2Q9si0S058268; Sat, 26 Mar 2011 11:54:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2Q9siUx058267; Sat, 26 Mar 2011 11:54:44 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 11:54:44 +0200 From: Kostik Belousov To: Jeremy Chadwick Message-ID: <20110326095444.GV78089@deviant.kiev.zoral.com.ua> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> <20110326051643.GA43364@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EZgzwfcZ9700+6Z+" Content-Disposition: inline In-Reply-To: <20110326051643.GA43364@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:55:27 -0000 --EZgzwfcZ9700+6Z+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 25, 2011 at 10:16:43PM -0700, Jeremy Chadwick wrote: > Why would the disk number change on a drive swap? This doesn't happen > on my Intel ICH9R controller on *any* Supermicro X7xxx or Supermicro > PDxxx board I have access to. Because the order of enumeration of controllers depends on the BIOS, and is not consistent among boots. Also, it changes if you swap controllers or insert disks into the free bays in the backplane. --EZgzwfcZ9700+6Z+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2Nt+MACgkQC3+MBN1Mb4g46gCgqcjbTrpGwP6qHJ+oGiNSeU3V BdwAoLoOKq3y98J/PhS0mwqrgy2gXLxV =SjLB -----END PGP SIGNATURE----- --EZgzwfcZ9700+6Z+-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 09:58:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DF43106564A; Sat, 26 Mar 2011 09:58:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2324E8FC17; Sat, 26 Mar 2011 09:58:13 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2Q9wAoD079892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 11:58:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2Q9wAFG058301; Sat, 26 Mar 2011 11:58:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2Q9wAnr058300; Sat, 26 Mar 2011 11:58:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 11:58:10 +0200 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20110326095810.GW78089@deviant.kiev.zoral.com.ua> References: <650638.91967.qm@web113506.mail.gq1.yahoo.com> <86wrjmtiab.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WcefIMV7bKFlmpJx" Content-Disposition: inline In-Reply-To: <86wrjmtiab.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, giffunip@tutopia.com Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:58:14 -0000 --WcefIMV7bKFlmpJx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 10:09:16AM +0200, Mikolaj Golub wrote: >=20 > On Fri, 25 Mar 2011 18:01:39 -0700 (PDT) Pedro F. Giffuni wrote: >=20 > PFG> --- On Fri, 3/25/11, Kostik Belousov wrote: >=20 > PFG> .... > >> No, I do not want it in our testing framework. I want to > >> see a standalone test that demonstrates the issue. > >> I think the leak is real, but want to have a way to > >> reproduce it before committing. > >>=20 > >> The diff you pointed out to t_vnops.c does not make much > >> sense to me. >=20 > PFG> I looked a little more in their records and I found this: > PFG> _____ > PFG> ... > PFG> /* rename directory over an empty directory */ > PFG> md(pb1, mp, "parent"); > PFG> md(pb2, mp, "parent/dir1"); > PFG> md(pb3, mp, "parent/dir2"); > PFG> RL(rump_sys_mkdir(pb1, 0777)); > PFG> RL(rump_sys_mkdir(pb2, 0777)); > PFG> RL(rump_sys_mkdir(pb3, 0777)); > PFG> RL(rump_sys_rename(pb2, pb3)); >=20 > PFG> RL(rump_sys_stat(pb1, &sb)); > PFG> ATF_CHECK_EQ(sb.st_nlink, 3); > PFG> RL(rump_sys_rmdir(pb3)); > PFG> if (FSTYPE_TMPFS(tc)) > PFG> atf_tc_expect_signal(-1, "PR kern/44288"); > PFG> ______ >=20 > PFG> There's also this that was removed once the PR was fixed: >=20 > PFG> - if (FSTYPE_MSDOS(tc)) > PFG> - atf_tc_skip("test fails in some setups, reason unk= nown"); >=20 > PFG> hope that helps. >=20 > I suppose doing something like this on msdos fs: >=20 > mkdir parent > mkdir parent/1 > mv parent/1 parent/2 > ls -dl parent >=20 > In the case of the leak we should see 4 in hard links number field instea= d of > expected 3. No, the supposed leak only affects the vnode usecount, and not the inode hardlink count. The later is indeed reported as 1 for FreeBSD implementation of msdosfs, AFAIR. Probably, the only way to verify the case is to use debugger. >=20 > But in FreeBSD it looks like msdosfs always reports link count 1: >=20 > /dev/md1 on /mnt (msdosfs, local) >=20 > [root@lolek ~]# cd /mnt/ > [root@lolek /mnt]# mkdir parent > [root@lolek /mnt]# mkdir parent/1 parent/2 parent/3 > [root@lolek /mnt]# ls -ld parent > drwxr-xr-x 1 root wheel 4096 Mar 26 11:56 parent >=20 > Tested on 8-STABLE and CURRENT. >=20 > --=20 > Mikolaj Golub --WcefIMV7bKFlmpJx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2NuLEACgkQC3+MBN1Mb4jQ1gCgwMdaYagMcmerEE6MP9ZA708r mTEAn1hBH8cevyMd7b3XZIULuIf0Yrk4 =m15b -----END PGP SIGNATURE----- --WcefIMV7bKFlmpJx-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 10:09:44 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB0C106566B for ; Sat, 26 Mar 2011 10:09:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id A13928FC12 for ; Sat, 26 Mar 2011 10:09:43 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id Pm9C1g0031ei1Bg57m9jNJ; Sat, 26 Mar 2011 10:09:43 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.westchester.pa.mail.comcast.net with comcast id Pm9i1g0041t3BNj3km9ji1; Sat, 26 Mar 2011 10:09:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 604819B429; Sat, 26 Mar 2011 03:09:41 -0700 (PDT) Date: Sat, 26 Mar 2011 03:09:41 -0700 From: Jeremy Chadwick To: Kostik Belousov Message-ID: <20110326100941.GA50429@icarus.home.lan> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> <20110326051643.GA43364@icarus.home.lan> <20110326095444.GV78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110326095444.GV78089@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 10:09:44 -0000 On Sat, Mar 26, 2011 at 11:54:44AM +0200, Kostik Belousov wrote: > On Fri, Mar 25, 2011 at 10:16:43PM -0700, Jeremy Chadwick wrote: > > Why would the disk number change on a drive swap? This doesn't happen > > on my Intel ICH9R controller on *any* Supermicro X7xxx or Supermicro > > PDxxx board I have access to. > Because the order of enumeration of controllers depends on the > BIOS, and is not consistent among boots. Also, it changes if you > swap controllers or insert disks into the free bays in the backplane. Re: insert disks into free bays: it behaves as I described in my post (paragraph #7): http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011039.html If someone wants me to prove it, I'll be more than happy to start removing/inserting disks on my system here at home to show exactly what happens (using ICH9xx with ahci.ko). I would prove it as well with our production machines but I'd have to physically be in the co-lo to swap the disk. :-) The OP only mentioned that he was concerned with device names changing if he swapped disks. I have not seen hot-swapping (specifically removal of old disk, insertion of new disk) result in the device number increasing -- ever. The OP didn't any mention of swapping or exchanging of controllers, adding new ones, removing others, etc.. yeah, these could induce device number changes, absolutely. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 11:34:49 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E62351065674 for ; Sat, 26 Mar 2011 11:34:49 +0000 (UTC) (envelope-from sergiy.suprun@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A4DEF8FC13 for ; Sat, 26 Mar 2011 11:34:49 +0000 (UTC) Received: by vxc34 with SMTP id 34so1624607vxc.13 for ; Sat, 26 Mar 2011 04:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=bwTq7LekSOj5UmlafUPpLArv/SqpzEQtp9zJ9u+mMTI=; b=ZqhK/fmta/hi5l+q7Z6pru2RxyqsIkyqQ7Wmnz4Sk37+ySCaVloxsCOryDpNnG54qR S32tJfu14J4xm5oJgazPXH4V7VnVYYKp9U0n19SbN3N+1t761Dpbtk6vkxBzeFW5Dp71 QYbCGj+tG+48h2luLFQyPF2DBQJbEZQEzBDnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Jvc5vozrRRi/rrUdE5mAqyAJNCcmDBoTzdADf2OOWVd5t3d4E4IFSx6pg+P3MrFgsd F3PJiaDrgRPfcigMISg+OvvBbMCVd6pnuo61x7TW7MIl/7P2lCt6+tWw+2S0cTBL8TB3 RDl+seVbCd4CaWPlKoqJ9pUlwQ0Is4CNsvcNQ= MIME-Version: 1.0 Received: by 10.220.122.39 with SMTP id j39mr545026vcr.78.1301137962206; Sat, 26 Mar 2011 04:12:42 -0700 (PDT) Received: by 10.220.194.141 with HTTP; Sat, 26 Mar 2011 04:12:42 -0700 (PDT) Date: Sat, 26 Mar 2011 13:12:42 +0200 Message-ID: From: Sergiy Suprun To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: raidz2 boot problem: "zfs: out of temporary buffer space" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 11:34:50 -0000 Hello list. Today I'm try to upgrade my ssytem from 8.0-stable to 8.2-relese. My server has 8 sas drives on dell LSI controller all configured as single drive array, so bios seen 8 drives. Before upgrade I'm use i386 and zfs v13, after upgrade system to amd64 I recieve error: zfs: out of temporary buffer space. First that I do is refresh bootcode on all 8 disks, after I upgrade zpool and zfs to latest version but no luck has same error. Bit more about my upgrade procedure: After csup'ing fresh sources I build kernel and world with TARGETARCH=amd64 and install it to /amd64, update loader.conf and zpool bootfs. If boot from 8.2-release Fixit I can see and import my zpool without any error. So where I'm wrong? Any ideas and recomendations are welcome. Thanks in advance!______ WBR Sergiy From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 12:04:26 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D4281065673; Sat, 26 Mar 2011 12:04:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 39C8E8FC1C; Sat, 26 Mar 2011 12:04:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2QC4M41090424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 14:04:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2QC4MA8059322; Sat, 26 Mar 2011 14:04:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2QC4L7v059321; Sat, 26 Mar 2011 14:04:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 14:04:21 +0200 From: Kostik Belousov To: giffunip@tutopia.com Message-ID: <20110326120421.GX78089@deviant.kiev.zoral.com.ua> References: <650638.91967.qm@web113506.mail.gq1.yahoo.com> <86wrjmtiab.fsf@kopusha.home.net> <20110326095810.GW78089@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="90Im4sMSctB4pvMl" Content-Disposition: inline In-Reply-To: <20110326095810.GW78089@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mikolaj Golub , freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 12:04:26 -0000 --90Im4sMSctB4pvMl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 11:58:10AM +0200, Kostik Belousov wrote: > On Sat, Mar 26, 2011 at 10:09:16AM +0200, Mikolaj Golub wrote: > >=20 > > On Fri, 25 Mar 2011 18:01:39 -0700 (PDT) Pedro F. Giffuni wrote: > >=20 > > PFG> --- On Fri, 3/25/11, Kostik Belousov wrote: > >=20 > > PFG> .... > > >> No, I do not want it in our testing framework. I want to > > >> see a standalone test that demonstrates the issue. > > >> I think the leak is real, but want to have a way to > > >> reproduce it before committing. > > >>=20 > > >> The diff you pointed out to t_vnops.c does not make much > > >> sense to me. > >=20 > > PFG> I looked a little more in their records and I found this: > > PFG> _____ > > PFG> ... > > PFG> /* rename directory over an empty directory */ > > PFG> md(pb1, mp, "parent"); > > PFG> md(pb2, mp, "parent/dir1"); > > PFG> md(pb3, mp, "parent/dir2"); > > PFG> RL(rump_sys_mkdir(pb1, 0777)); > > PFG> RL(rump_sys_mkdir(pb2, 0777)); > > PFG> RL(rump_sys_mkdir(pb3, 0777)); > > PFG> RL(rump_sys_rename(pb2, pb3)); > >=20 > > PFG> RL(rump_sys_stat(pb1, &sb)); > > PFG> ATF_CHECK_EQ(sb.st_nlink, 3); > > PFG> RL(rump_sys_rmdir(pb3)); > > PFG> if (FSTYPE_TMPFS(tc)) > > PFG> atf_tc_expect_signal(-1, "PR kern/44288"); > > PFG> ______ > >=20 > > PFG> There's also this that was removed once the PR was fixed: > >=20 > > PFG> - if (FSTYPE_MSDOS(tc)) > > PFG> - atf_tc_skip("test fails in some setups, reason u= nknown"); > >=20 > > PFG> hope that helps. > >=20 > > I suppose doing something like this on msdos fs: > >=20 > > mkdir parent > > mkdir parent/1 > > mv parent/1 parent/2 > > ls -dl parent > >=20 > > In the case of the leak we should see 4 in hard links number field inst= ead of > > expected 3. > No, the supposed leak only affects the vnode usecount, and not the > inode hardlink count. The later is indeed reported as 1 for FreeBSD > implementation of msdosfs, AFAIR. >=20 > Probably, the only way to verify the case is to use debugger. Ok, after rereading the code, I do not believe that we need the change. The doscheckpath() does vput() on tdvp, and tvp is vput'ed right before line 1083, so jumping to the label `bad' instead of `out' will only result in the lock assertion being fired. Also, the msdosfs mount correctly unmounts after the attempt to perform a rename that doscheckpath() banned. This is additional evidence supporting my point. The question is, why did you decided that the fix is needed for FreeBSD ? > >=20 > > But in FreeBSD it looks like msdosfs always reports link count 1: > >=20 > > /dev/md1 on /mnt (msdosfs, local) > >=20 > > [root@lolek ~]# cd /mnt/ > > [root@lolek /mnt]# mkdir parent > > [root@lolek /mnt]# mkdir parent/1 parent/2 parent/3 > > [root@lolek /mnt]# ls -ld parent > > drwxr-xr-x 1 root wheel 4096 Mar 26 11:56 parent > >=20 > > Tested on 8-STABLE and CURRENT. > >=20 > > --=20 > > Mikolaj Golub --90Im4sMSctB4pvMl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2N1kUACgkQC3+MBN1Mb4hnJwCdG+Ou3Zh8pvEEk0gk9GkWWGI1 vGYAnRHc5/KsJpJdQ920DQRM8wovd5/R =e9eS -----END PGP SIGNATURE----- --90Im4sMSctB4pvMl-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 13:30:42 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 885FB106566C for ; Sat, 26 Mar 2011 13:30:42 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.213.67.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5F0128FC08 for ; Sat, 26 Mar 2011 13:30:42 +0000 (UTC) Received: from localhost (unknown [172.16.100.24]) by mail.barafranca.com (Postfix) with ESMTP id 80CB4567 for ; Sat, 26 Mar 2011 13:30:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at barafranca.com Received: from mail.barafranca.com ([172.16.100.24]) by localhost (mail.barafranca.com [172.16.100.24]) (amavisd-new, port 10024) with ESMTP id TfScSwVj8HPM for ; Sat, 26 Mar 2011 13:29:59 +0000 (UTC) Received: from [192.168.1.1] (raskin.torservers.net [74.120.15.150]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTPSA id AE4E4560 for ; Sat, 26 Mar 2011 13:29:55 +0000 (UTC) Message-ID: <4D8DEA4A.8010502@barafranca.com> Date: Sat, 26 Mar 2011 13:29:46 +0000 From: Hugo Silva User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: MySQL HA with hast X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:30:42 -0000 Hello, Yesterday I was toying with the idea of using hast and MySQL for HA. I went over the idea in my head and on paper and in principle it looks plausible. Since I don't have the hardware right now, and before starting to create VMs like a mad man, I thought, why not ask the list first? Has anyone tried this combo? From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 13:40:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B5F4106566B for ; Sat, 26 Mar 2011 13:40:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id D26E38FC0A for ; Sat, 26 Mar 2011 13:40:34 +0000 (UTC) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2QDOD76002877 for ; Sun, 27 Mar 2011 00:24:13 +1100 Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2QDO3IE009676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Mar 2011 00:24:04 +1100 Date: Sun, 27 Mar 2011 00:24:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> Message-ID: <20110327000956.U1316@besplex.bde.org> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:40:35 -0000 On Sat, 26 Mar 2011, Kostik Belousov wrote: > On Fri, Mar 25, 2011 at 05:21:50PM -0700, Michael DeMan wrote: >> Hi All, >> >> I seem to recall that there is a way to do this, but can no longer google it. >> >> Basically, for NCQ support with SATA devices we are using the 'ada' driver, which of course has SCSI like behavior. >> ... > I use the following stanza in /boot/device.hints for machine with intel > on-board ahci and siis in pcie: > hint.scbus.0.at="ahcich0" > hint.ada.0.at="scbus0" > hint.scbus.1.at="ahcich1" > hint.ada.1.at="scbus1" > hint.scbus.2.at="ahcich2" > hint.ada.2.at="scbus2" > hint.scbus.3.at="ahcich3" > hint.ada.3.at="scbus3" > hint.scbus.4.at="ahcich4" > hint.ada.4.at="scbus4" > hint.scbus.5.at="siisch0" > hint.ada.5.at="scbus5" > hint.scbus.6.at="siisch1" > hint.ada.6.at="scbus6" To hijack this thread a little, I'll ask how people handle removable media changing the addresses of non-removable media. I use the following to prevent USB drives stealing da0 from my 1 real SCSI disk on 1 machine: hint.scbus.0.at="sym0" hint.da.0.at="scbus0" This works OK and is easy to manage with only 1 SCSI disk. But 1 of my USB drives also steals cd0 from a not-so-real ATAPI drive under atapicam, depending on whether the USB drive is present at boot time: USB drive not present at boot time: ad* (no SCSI disks on this machine) cd0 = acd0 (but no further ATAPI drives on this machine) insert USB drive: da1 (da0 was reserved by above) cd1 (phantom ATAPI drive on the USB drive. Accessing this hangs parts of the ata system but it doesn't get used since various places only point cd0) USB drive present at boot time: ad* da1 on USB cd0 phantom on USB cd1 = acd[0 or 1] (normal cd0). Accessing cd0 now hangs parts of the ata system and this happens too easily since various places point to cd0. How do people defend agains random USB drives present or not at boot time? Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 13:52:20 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4C131065675 for ; Sat, 26 Mar 2011 13:52:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5FC8FC0C for ; Sat, 26 Mar 2011 13:52:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2QDqBtZ098895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 15:52:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2QDqBGi059825; Sat, 26 Mar 2011 15:52:11 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2QDqBRm059824; Sat, 26 Mar 2011 15:52:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 15:52:11 +0200 From: Kostik Belousov To: Bruce Evans Message-ID: <20110326135211.GB78089@deviant.kiev.zoral.com.ua> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> <20110327000956.U1316@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LsLZkRs1u+fwC9y3" Content-Disposition: inline In-Reply-To: <20110327000956.U1316@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:52:20 -0000 --LsLZkRs1u+fwC9y3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 27, 2011 at 12:24:03AM +1100, Bruce Evans wrote: > On Sat, 26 Mar 2011, Kostik Belousov wrote: >=20 > >On Fri, Mar 25, 2011 at 05:21:50PM -0700, Michael DeMan wrote: > >>Hi All, > >> > >>I seem to recall that there is a way to do this, but can no longer goog= le=20 > >>it. > >> > >>Basically, for NCQ support with SATA devices we are using the 'ada'=20 > >>driver, which of course has SCSI like behavior. > >>... > >I use the following stanza in /boot/device.hints for machine with intel > >on-board ahci and siis in pcie: > >hint.scbus.0.at=3D"ahcich0" > >hint.ada.0.at=3D"scbus0" > >hint.scbus.1.at=3D"ahcich1" > >hint.ada.1.at=3D"scbus1" > >hint.scbus.2.at=3D"ahcich2" > >hint.ada.2.at=3D"scbus2" > >hint.scbus.3.at=3D"ahcich3" > >hint.ada.3.at=3D"scbus3" > >hint.scbus.4.at=3D"ahcich4" > >hint.ada.4.at=3D"scbus4" > >hint.scbus.5.at=3D"siisch0" > >hint.ada.5.at=3D"scbus5" > >hint.scbus.6.at=3D"siisch1" > >hint.ada.6.at=3D"scbus6" >=20 > To hijack this thread a little, I'll ask how people handle removable media > changing the addresses of non-removable media. I use the following to > prevent USB drives stealing da0 from my 1 real SCSI disk on 1 machine: >=20 > hint.scbus.0.at=3D"sym0" > hint.da.0.at=3D"scbus0" >=20 > This works OK and is easy to manage with only 1 SCSI disk. But 1 of my > USB drives also steals cd0 from a not-so-real ATAPI drive under atapicam, > depending on whether the USB drive is present at boot time: >=20 > USB drive not present at boot time: > ad* (no SCSI disks on this machine) > cd0 =3D acd0 (but no further ATAPI drives on this machine) > insert USB drive: > da1 (da0 was reserved by above) > cd1 (phantom ATAPI drive on the USB drive. Accessing this hangs > parts of the ata system but it doesn't get used since various > places only point cd0) >=20 > USB drive present at boot time: > ad* > da1 on USB > cd0 phantom on USB > cd1 =3D acd[0 or 1] (normal cd0). Accessing cd0 now hangs parts of = the > ata system and this happens too easily since various places point > to cd0. >=20 > How do people defend agains random USB drives present or not at boot time? Wouldn't it be cd0 on scbusX on ahciY, and cd1 on scbusZ on umass-simT ? I believe similar hints would wire the cd0/cd1 in your case. >=20 > Bruce --LsLZkRs1u+fwC9y3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2N74oACgkQC3+MBN1Mb4hi1QCgw/ObHcf5p7Xh8+m+gBWZx02x Lh8AoPRvGEZ+L5QDNypkUCSVAyVLac0T =O+Z3 -----END PGP SIGNATURE----- --LsLZkRs1u+fwC9y3-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 14:12:06 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 779C1106564A for ; Sat, 26 Mar 2011 14:12:06 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm8.bullet.mail.sp2.yahoo.com (nm8.bullet.mail.sp2.yahoo.com [98.139.91.78]) by mx1.freebsd.org (Postfix) with SMTP id 529538FC0C for ; Sat, 26 Mar 2011 14:12:06 +0000 (UTC) Received: from [98.139.91.63] by nm8.bullet.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 14:12:05 -0000 Received: from [98.139.91.33] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 14:12:05 -0000 Received: from [127.0.0.1] by omp1033.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 14:12:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 935660.66135.bm@omp1033.mail.sp2.yahoo.com Received: (qmail 68680 invoked by uid 60001); 26 Mar 2011 14:12:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301148725; bh=U72zgvIzVdTDwbm0D/hBUxnFfJb02PMO6ZdQg8zC4kY=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jvk93OPMW+5yzrMN0lLn9d3vv8/tRcVlh7SefDYFm4m34n2BRuckltn1ZnVlEMZqWd+fbXiGZWNVavGSL2lWYLGIfYwlfYVcofaCTOF3pHx3vv35nIlQFzWgiBj/uPlMksvdN59wEfVicyZJ4ICb1nkbsCPRNJhH2eJR+GjKZm8= Message-ID: <553011.63188.qm@web113509.mail.gq1.yahoo.com> X-YMail-OSG: rxgquwgVM1nnyBt_HUxuKUZahUhEf.y30yL3Atakx5akS0Q jPXfQnGZP_ivbcCfPH1sKxErjjc74J4CaPqWGpj7Hh5qSorU.Bypee_QVM1r qYT57k4rybBFnJ1KZSq466F0L7Ii8F1gWSRb1aJjAzd1xquE9SqOBVlJRg8O a6y_74LZLFVEHisg0MJc412v_SRgSPvYQzqC6fJ8VZBaxscMfQatRe13Bxlx siXFmkp17n5Olgmxr1QiuIsOxmEmnvF7TWNh62BuDxpLIXx.FwQz_hKQBe8y 0RX1A6TEeZOCO230OrbOgOJFcCSRrlZ3cJL8W1_xKz4.nPDjVl8dQ.u71M94 DFsDfw9cK0po7g1huG7GFZucsnNbSR_0YRmDsbNvrT3H_vZGCghoIx0j8jhb qQ6M1ME4w5bjp Received: from [200.118.159.55] by web113509.mail.gq1.yahoo.com via HTTP; Sat, 26 Mar 2011 07:12:05 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Sat, 26 Mar 2011 07:12:05 -0700 (PDT) From: "Pedro F. Giffuni" To: Kostik Belousov In-Reply-To: <20110326120421.GX78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mikolaj Golub , freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:12:06 -0000 --- On Sat, 3/26/11, Kostik Belousov wrote: ... > Ok, after rereading the code, I do not believe that we need > the change. The doscheckpath() does vput() on tdvp, and tvp > is vput'ed right before line 1083, so jumping to the label > `bad' instead of `out' will only result in the lock > assertion being fired. > > Also, the msdosfs mount correctly unmounts after the > attempt to perform a rename that doscheckpath() banned. > This is additional evidence supporting my point. > > The question is, why did you decided that the fix is needed > for FreeBSD ? > Defensive programming. On NetBSD this apparently started causing problems for unknown reasons, and doing the change doesn't have any ill effect on FreeBSD. I am OK, if you want to close the PR though, and thanks for doing the complete research. Pedro. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 14:16:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADA3A1065670; Sat, 26 Mar 2011 14:16:27 +0000 (UTC) (envelope-from mickael.maillot@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4478FC13; Sat, 26 Mar 2011 14:16:26 +0000 (UTC) Received: by qyk35 with SMTP id 35so243588qyk.13 for ; Sat, 26 Mar 2011 07:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OO6A4ve/z4ceNyUNBvrRm6nM3wvPP4SOfEjKyUxLvQU=; b=wG5iD4bOOzufXKXMvwpWloYjSt7a9SURgzvc6j2eiS1d6WYkGr89MlVNufFiTpqKn+ g07AchbhXRC4klT1miBlzPlttSvcpzo/OM/QOxXA/kK+kTtWn8c2Dw7jrYzIshnztycC zDHHiQR3SlMpY/0GtpghcGoMzyzHFlLDxBBVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IP1iC6KNUK07Gl8K5oxl5X3rhjKgU7CPf2HIOkSH1BO49d28Yim8/8ppoi3R7xTOEW 6MtRnHdXRmWXtEDaonJAqvy3gRAuNvgkaNyX1buSzTYutgrXUVfsh7JsHPrTnO81NS98 c0JZydOOUhR9eZkWbBppkhIKd6mLPtBZS+ypM= MIME-Version: 1.0 Received: by 10.229.240.72 with SMTP id kz8mr705034qcb.20.1301147622597; Sat, 26 Mar 2011 06:53:42 -0700 (PDT) Received: by 10.229.130.162 with HTTP; Sat, 26 Mar 2011 06:53:42 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Mar 2011 14:53:42 +0100 Message-ID: From: =?ISO-8859-1?Q?Micka=EBl_Maillot?= To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Filesystems , FreeBSD-Current , FreeBSD Stable Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:16:27 -0000 Hi, 2011/3/24 Freddie Cash : > The hardware is fairly standard fare: > =A0- SuperMicro H8DGi-F motherboard > =A0- AMD Opteron 6100-series CPU (8-cores @ 2.0 GHz) > =A0- 8 GB DDR3 SDRAM > =A0- 64 GB Kingston V-Series SSD for the OS install (using ahci(4) and > the motherboard SATA controller) > =A0- 3x SuperMicro AOC-USAS2-8Li SATA controllers with IT firmware > =A0- 6x 1.5 TB Seagate 7200.11 drives (1x raidz2 vdev) > =A0- 12x 1.0 TB Seagate 7200.12 drives (2x raidz2 vdev) > =A0- 6x 0.5 TB WD RE3 drives (1x raidz2 vdev) just for info, sun recommend 1 Gb of RAM per Tera of data. i see here ~ 16 To of available data, so i would recommend 16 Gb for arc_size and 24 or 32 Gb for the host. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 14:42:58 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE8DB106566C for ; Sat, 26 Mar 2011 14:42:58 +0000 (UTC) (envelope-from pipatron@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4B18FC0C for ; Sat, 26 Mar 2011 14:42:58 +0000 (UTC) Received: by yxl31 with SMTP id 31so885256yxl.13 for ; Sat, 26 Mar 2011 07:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=l7HZOXhe9ZtZ3rPOJQZJjBLW2JergD0E/6IAGWZYR8E=; b=cgSDP5klwQpiiUr5D8HF180PHGwH0oaJJJ4uKMqFVpgptmNSZ6uiDeO9xMSZgyQ7nr ns9a0waWNQjcs7YwWzIaRrSCF2m8Z6so526K9gMFAu4T0ZZkisJoq9TOi5i144xG96F9 hU1/gQk4kdm+/wJbPoWJ7smOizw5HB7bwE8NE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=l58fwP2Y3dexAtuLcUxU3VDVamDb9cQwDXPDMssCGC1WBUNkfyzGqgxy6HQqytjvca Io0lNcKayh+yv40KnIq77l0fiFRaBzCilWCzokctQmtK3lWb0u+D53o5mJo6/OOaZNfc SyIJ8jGiKVFvGkgGI7IE2XPbyX/osiAMY/Fuc= MIME-Version: 1.0 Received: by 10.236.154.166 with SMTP id h26mr2946430yhk.186.1301150577888; Sat, 26 Mar 2011 07:42:57 -0700 (PDT) Received: by 10.147.35.6 with HTTP; Sat, 26 Mar 2011 07:42:57 -0700 (PDT) Date: Sat, 26 Mar 2011 15:42:57 +0100 Message-ID: From: Anders Andersson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: RAID-Z in a disk-failure. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:42:58 -0000 Evening! I have a question about ZFS in a FreeBSD setting, more specifically about RAID-Z. I have never used ZFS so I might have misunderstood something, but imagine this situation: You're using ZFS in RAID-Z with 4 disks. One of these gets a catastrophic failure. You replace the disk with a new one, but when the RAID-Z is rebuilt, the software notices that one sector/block on another disk has become corrupted. It notices this because ZFS keeps a checksum. What happens then? Since the redundancy is temporarily disabled because of the failed disk, this sector/block is nowhere to be found. My hope is that the system will handle this gracefully, so that only the file using this block will be unreadable, but the rest of the data is available and can be rebuilt. The worst that could happen is that the rebuild is refused and the whole pool is gone. Have I missed something in this scenario? // Anders From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 14:52:14 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CA6C106566B; Sat, 26 Mar 2011 14:52:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D566C8FC0A; Sat, 26 Mar 2011 14:52:13 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2QEqAeD003773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 16:52:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2QEqA8P060070; Sat, 26 Mar 2011 16:52:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2QEqA5s060069; Sat, 26 Mar 2011 16:52:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 16:52:10 +0200 From: Kostik Belousov To: "Pedro F. Giffuni" Message-ID: <20110326145210.GD78089@deviant.kiev.zoral.com.ua> References: <20110326120421.GX78089@deviant.kiev.zoral.com.ua> <553011.63188.qm@web113509.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ISPgvyEoImXrYgMr" Content-Disposition: inline In-Reply-To: <553011.63188.qm@web113509.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mikolaj Golub , freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:52:14 -0000 --ISPgvyEoImXrYgMr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 07:12:05AM -0700, Pedro F. Giffuni wrote: >=20 > --- On Sat, 3/26/11, Kostik Belousov wrote: >=20 > ... > > Ok, after rereading the code, I do not believe that we need > > the change. The doscheckpath() does vput() on tdvp, and tvp > > is vput'ed right before line 1083, so jumping to the label > > `bad' instead of `out' will only result in the lock > > assertion being fired. > >=20 > > Also, the msdosfs mount correctly unmounts after the > > attempt to perform a rename that doscheckpath() banned. > > This is additional evidence supporting my point. > >=20 > > The question is, why did you decided that the fix is needed > > for FreeBSD ? > > >=20 > Defensive programming. On NetBSD this apparently started > causing problems for unknown reasons, and doing the change > doesn't have any ill effect on FreeBSD. What is defensive in introducing the bug ? The change, applied to FreeBSD, will cause panic. >=20 > I am OK, if you want to close the PR though, and thanks for > doing the complete research. >=20 > Pedro. >=20 >=20 >=20 > =20 --ISPgvyEoImXrYgMr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2N/ZkACgkQC3+MBN1Mb4iMHQCg2gfCka+SyfkCmSfecjiftFBy tCEAnAs8HUG0Yu1TSOMJRd0sTQDWeQYg =pbbB -----END PGP SIGNATURE----- --ISPgvyEoImXrYgMr-- From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 14:53:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06BA41065677 for ; Sat, 26 Mar 2011 14:53:41 +0000 (UTC) (envelope-from pipatron@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7A738FC16 for ; Sat, 26 Mar 2011 14:53:40 +0000 (UTC) Received: by gxk28 with SMTP id 28so871022gxk.13 for ; Sat, 26 Mar 2011 07:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wR8oTcf62bZTpZJ8wqxdtT3igSvWQjINXpYefhLI9g8=; b=m1SA8kZnoba6+6XlUPIvCzCaN7ZK5rZhzAzueipoCCkXPv+JxdtHgiTUo7LTVriHCH SvOC6M/uWcNgeSkeQpF7x0/UwMNbCnfLU5SRb/7IKGCJbT+nWjBqAWdTodRDdWMXfau8 cjySdUvWmWIR82YvRYOjwgWLP+xQqNT8a+Aho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WILYiBJsuSL/3Tp1hPUoERpMMROQ9Hsvwnu0OgFUArKShPyC8LsQ61g9cumTMeFf8t gJ+hpCprdLaS1Tj4tX4/UqTB9JrZjDdNOlvXnNr1ZeeSYEzla9rbrTUUWP7EfY/t8T8T fIA1TsjHriwnTXVs+hF3a26o3Klp0AAN5v8t0= MIME-Version: 1.0 Received: by 10.150.169.16 with SMTP id r16mr1372517ybe.335.1301149629261; Sat, 26 Mar 2011 07:27:09 -0700 (PDT) Received: by 10.147.35.6 with HTTP; Sat, 26 Mar 2011 07:27:09 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Mar 2011 15:27:09 +0100 Message-ID: From: Anders Andersson To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: Recover a ufs2 filesystem from a reformat with another ufs2 filesystem X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:53:41 -0000 Dear list! I realized that I never replied with a follow-up to this problem I had, and even though a long time have passed I want to explain what I did so that others in a similar situation can read about it. On Mon, Feb 14, 2011 at 1:35 AM, Ivan Voras wrote: > On 13/02/2011 21:39, Anders Andersson wrote: > >> 1) If an old file system is overwritten by a new file system with the >> same size, are there any traces of the old file system meta data left? >> I'm thinking randomized backup headers scattered throughout the file >> system, which would have a different location after each new format. > > No, not randomized at all, unfortunately for your purpose - there are copies > of superblocks, but all important data is on precisely deterministic > positions for somewhat the same reasons - to help recovery in case parts of > it are missing. Perhaps it would be beneficial if some of this information was spread out at random for recover purpose, although I don't know what bad side effects this would create. >> 4) If everything else fails, can you recommend a good overview about >> UFS2, how and where the bits and pieces are stored on disk? > > That would be a very complicated but also very interesting way to learn in > extreme details about a file system :) The more you learn, the better. :) I never went to this length though. I ended up just using photorec/magicrescue on the block device to find at least some photos and documents. > In any case, as others said, DO NOT WORK ON THE "LIVE" HARD DRIVE. Make a > copy image of it. Naturally. Though I had to do some extra trickery here since I didn't have 2TB spare to take a full backup. What I did was to use the device mapper subsystem in linux to create writable snapshots over the read-only master. Having multiple writable snapshots is handy when comparing things. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 15:23:37 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14C91065672 for ; Sat, 26 Mar 2011 15:23:37 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0348FC15 for ; Sat, 26 Mar 2011 15:23:37 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id p2QFNaae007631; Sat, 26 Mar 2011 10:23:36 -0500 (CDT) Date: Sat, 26 Mar 2011 10:23:36 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Anders Andersson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sat, 26 Mar 2011 10:23:36 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: RAID-Z in a disk-failure. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 15:23:37 -0000 On Sat, 26 Mar 2011, Anders Andersson wrote: > > Have I missed something in this scenario? I think that your summary is pretty accurate. However, it is worth noting that zfs stores redundant copies of metadata blocks, and may optionally store redundant copies of user data blocks. Zfs offers raidz2 for the same reasons that storage array vendors offer RAID6 (vs RAID5). With today's large disks, a secondary data failure is not unlikely. If you use zfs mirroring or raidz1, then a periodic zfs scrub is recommended in order to decrease the possibility of secondary data failure. I would definitely do an initial zfs scrub after initially populating a pool with data. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 16:51:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96D2A106564A for ; Sat, 26 Mar 2011 16:51:22 +0000 (UTC) (envelope-from giffunip@tutopia.com) Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by mx1.freebsd.org (Postfix) with SMTP id 71B3C8FC0C for ; Sat, 26 Mar 2011 16:51:22 +0000 (UTC) Received: from [98.139.91.70] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 16:51:21 -0000 Received: from [98.139.91.18] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 16:51:21 -0000 Received: from [127.0.0.1] by omp1018.mail.sp2.yahoo.com with NNFMP; 26 Mar 2011 16:49:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 184047.65484.bm@omp1018.mail.sp2.yahoo.com Received: (qmail 40084 invoked by uid 60001); 26 Mar 2011 16:49:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301158193; bh=SDwqEejjFr7RVFjJfKv+KKcpL23MKA2c8ygZs948L2A=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sc21HdbIvO/E+t+uIoBDm/0t84iEMX0+xJcRhe+32SNL2tOl+2sOxCnExv5F+0/C3cq0V1InlQzXZXiXyfqaMI2MJNv2Jzr0Os0MxR07xHMAxPMugLPLVkaRlKVS1+bK2/dxgJcE8RJBUAJ+Cg1UKaA6YXKZWFg4X1lpAThKlms= Message-ID: <655808.35503.qm@web113514.mail.gq1.yahoo.com> X-YMail-OSG: 3Z1LxbQVM1lM26Kr4AzGew4uOyKnsU456YS04hy2PK6cnkJ HL0O.GXxYvF3LMQsv83mDBWeOOZ827pCH2bcWArPUNoTlPifAtFgTyr5r404 GrZHyTi6qwrDfrSyiPvzNs8qpCpgSfRkRFYGzLy1BXnYfGo1M1aFopzYADOV cYUBxGFD9Pg_so9XnBQRj79nXuXiYdadauF.eabCVyl.9_fmJ0znS8R7DuQR mMvnh3DqjF6l408SF9RxiZKFnjmVwKRw2MQb8S0DfPmr9jxoXzgOQ.9rrVzS nRI8Ggw.Gh1QA4ozmnLfN0I60fta.6TmLHCRv9YVFETrI4c.1h14OJSsk6HY 9GNxm7EdyAXnqK0GHeYBpgoaDzSFFECmXC9qahOoV2Iimj.fn69nt4cfvgsj nMGTcNSmCPWv5 Received: from [200.118.159.55] by web113514.mail.gq1.yahoo.com via HTTP; Sat, 26 Mar 2011 09:49:53 PDT X-RocketYMMF: giffunip X-Mailer: YahooMailClassic/12.0.2 YahooMailWebService/0.8.109.295617 Date: Sat, 26 Mar 2011 09:49:53 -0700 (PDT) From: "Pedro F. Giffuni" To: Kostik Belousov In-Reply-To: <20110326145210.GD78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mikolaj Golub , freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: giffunip@tutopia.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 16:51:22 -0000 --- On Sat, 3/26/11, Kostik Belousov wrote: ... > > > > > Defensive programming. On NetBSD this apparently > > started causing problems for unknown reasons, > > and doing the change > > doesn't have any ill effect on FreeBSD. > What is defensive in introducing the bug ? > The change, applied to FreeBSD, will cause panic. > Oops.. I haven't experienced it (yet) but I'll surely refrain from submitting similar patches. Sorry! Pedro. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 17:00:20 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE7A91065672 for ; Sat, 26 Mar 2011 17:00:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8416B8FC16 for ; Sat, 26 Mar 2011 17:00:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QH0KJL057478 for ; Sat, 26 Mar 2011 17:00:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2QH0Kii057469; Sat, 26 Mar 2011 17:00:20 GMT (envelope-from gnats) Date: Sat, 26 Mar 2011 17:00:20 GMT Message-Id: <201103261700.p2QH0Kii057469@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Pedro F. Giffuni" Cc: Subject: Re: kern/152079: msdosfs: Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Pedro F. Giffuni" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:00:20 -0000 The following reply was made to PR kern/152079; it has been noted by GNATS. From: "Pedro F. Giffuni" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/152079: msdosfs: Small cleanups from the other NetBSD/OpenBSD Date: Sat, 26 Mar 2011 09:54:03 -0700 (PDT) Please close this PR. Apparently the last submission would introduce a panic in FreeBSD. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 17:20:08 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C053106564A for ; Sat, 26 Mar 2011 17:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DF9958FC08 for ; Sat, 26 Mar 2011 17:20:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QHK7sc076461 for ; Sat, 26 Mar 2011 17:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2QHK7N5076460; Sat, 26 Mar 2011 17:20:07 GMT (envelope-from gnats) Date: Sat, 26 Mar 2011 17:20:07 GMT Message-Id: <201103261720.p2QHK7N5076460@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: "Pedro F. Giffuni" Cc: Subject: Re: kern/142401: [ntfs] [patch] Minor updates to NTFS from NetBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Pedro F. Giffuni" List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:20:08 -0000 The following reply was made to PR kern/142401; it has been noted by GNATS. From: "Pedro F. Giffuni" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/142401: [ntfs] [patch] Minor updates to NTFS from NetBSD Date: Sat, 26 Mar 2011 10:06:26 -0700 (PDT) Let's just close this, it's rather cosmetic and uninteresting to FreeBSD. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 17:31:22 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA9D51065670 for ; Sat, 26 Mar 2011 17:31:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7954E8FC13 for ; Sat, 26 Mar 2011 17:31:21 +0000 (UTC) Received: by gyg13 with SMTP id 13so899754gyg.13 for ; Sat, 26 Mar 2011 10:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tTz4S97HTtO0PtS72r06laKkfKz9ExZ9aQWTvXhi/jk=; b=ANZHb5aF7CZgevC3era09PsLwgHAIaizFGCDDzq+G6bTcBS21kC9t7UY3mm8CbickR /cGZyZzDMJuJb60g7TeEqoQKzF0f8N/NJQ4d9bBHUNGC5GXP4Szpn/jK+pNLjPcxIzXT NkAivGLHSVR68It15hekHEq2ghkAPQLoRybWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ViBWUeUUDQcvWZptjBjE5B+SCaj4JJ9gi+WrIz4S9i8UEbMu9yl1lzPDb6nXb8yLib v0mv/wUI1c7ZZQJI85dOUw1O7rKLhNjD+9oRFor61gZmdl12FkJb2OqTKJfJhN4qL6zJ IA9bAXuM0xkJ6FXySmn9ivH6/LRw6N8KfzETA= MIME-Version: 1.0 Received: by 10.91.160.15 with SMTP id m15mr2150549ago.181.1301160680829; Sat, 26 Mar 2011 10:31:20 -0700 (PDT) Received: by 10.90.100.10 with HTTP; Sat, 26 Mar 2011 10:31:20 -0700 (PDT) In-Reply-To: <4D8DEA4A.8010502@barafranca.com> References: <4D8DEA4A.8010502@barafranca.com> Date: Sat, 26 Mar 2011 10:31:20 -0700 Message-ID: From: Freddie Cash To: Hugo Silva Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: MySQL HA with hast X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:31:22 -0000 On Sat, Mar 26, 2011 at 6:29 AM, Hugo Silva wrote: > Yesterday I was toying with the idea of using hast and MySQL for HA. I > went over the idea in my head and on paper and in principle it looks > plausible. > > Since I don't have the hardware right now, and before starting to create > VMs like a mad man, I thought, why not ask the list first? > > Has anyone tried this combo? Look in the archives for this very week. :) Pete French posted that he did this successfully. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 17:38:56 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39AD5106564A for ; Sat, 26 Mar 2011 17:38:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E78D48FC16 for ; Sat, 26 Mar 2011 17:38:55 +0000 (UTC) Received: by gwb15 with SMTP id 15so919414gwb.13 for ; Sat, 26 Mar 2011 10:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+DaKUWatUaQm6vmgNeOUobHbULjLpJ5vdN1j8r46ZdM=; b=L9oEIvLtyk9fiqmgVIf7BuZFZ0V6wyHS0ltIresxYAgv7IYui2NekoCo+pCoz2W3iD 3pz7gsK1HLqA4aXYO+lc+OBlGW83N3DISlQBMCtijcARcu0MfZ7D4sGArJ37iA0+Ew5G TsM5EeScUAURj7f1kXKmoBKcK2x8iMHKQcNjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KZA0VHlcGc+rbCaFve2av0MWUs6LeKb59EFeXKI73X15/AIFu87Dd6/T+oN+2P4fWC DYJbHOddYXx0ru8iC20eyM+/46VRXdFdvuPdRIntSI6J9kmLw6NNKwOCDGRAeRx7+E0C LV3/8n2T/UqzEcF6sv+pat2Acm8xva0Ckn5Yk= MIME-Version: 1.0 Received: by 10.90.136.14 with SMTP id j14mr2180822agd.154.1301161134988; Sat, 26 Mar 2011 10:38:54 -0700 (PDT) Received: by 10.90.100.10 with HTTP; Sat, 26 Mar 2011 10:38:54 -0700 (PDT) In-Reply-To: <20110326100941.GA50429@icarus.home.lan> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> <20110326051643.GA43364@icarus.home.lan> <20110326095444.GV78089@deviant.kiev.zoral.com.ua> <20110326100941.GA50429@icarus.home.lan> Date: Sat, 26 Mar 2011 10:38:54 -0700 Message-ID: From: Freddie Cash To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:38:56 -0000 On Sat, Mar 26, 2011 at 3:09 AM, Jeremy Chadwick wrote: > On Sat, Mar 26, 2011 at 11:54:44AM +0200, Kostik Belousov wrote: >> On Fri, Mar 25, 2011 at 10:16:43PM -0700, Jeremy Chadwick wrote: >> > Why would the disk number change on a drive swap? =C2=A0This doesn't h= appen >> > on my Intel ICH9R controller on *any* Supermicro X7xxx or Supermicro >> > PDxxx board I have access to. >> Because the order of enumeration of controllers depends on the >> BIOS, and is not consistent among boots. Also, it changes if you >> swap controllers or insert disks into the free bays in the backplane. > > Re: insert disks into free bays: it behaves as I described in my post > (paragraph #7): > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011039.html > > If someone wants me to prove it, I'll be more than happy to start > removing/inserting disks on my system here at home to show exactly what > happens (using ICH9xx with ahci.ko). =C2=A0I would prove it as well with = our > production machines but I'd have to physically be in the co-lo to swap > the disk. =C2=A0:-) > > The OP only mentioned that he was concerned with device names changing > if he swapped disks. =C2=A0I have not seen hot-swapping (specifically > removal of old disk, insertion of new disk) result in the device number > increasing -- ever. Reread the original post. :) The point of the post is "how do you keep device bus enumeration the same across reboots". Reboot is mentioned a couple of times in the post. :) The OP wants to know how to populate X out of Y ports on a controller, and have the numbering remain the same across reboots, when adding/removing drives. Without using hint.* entries in /boot/loader.conf, you can't. AFAIK, there's not CAM-based equivalent to ATA_STATIC_NUMBERING in the kernel (or whatever that option is called). Thus, you have to resort to labelling the drives/partitions in one fashion or another, so that no matter what the underlying device node is, the "name" of the drive never changes. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 17:52:11 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A289106566C; Sat, 26 Mar 2011 17:52:11 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE5728FC08; Sat, 26 Mar 2011 17:52:10 +0000 (UTC) Received: by gyg13 with SMTP id 13so903155gyg.13 for ; Sat, 26 Mar 2011 10:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gFl7RXhTCF8VJI6KIcXXSFCS9Qk5RulCOlbde51Lu/0=; b=LT7Z8b/aTUd8DvcwEg6iyrKfTQvpEe9INway8SFNAa0ZzVqNbqMxWPs42qa/EFFP1H VOfjVxtsigkeBCvTtR6ICEJCF8b/kOWZyYkFaxmKCIZP6mwHixgQYcI5kOj7FzaAvPwT RD20E7zEr6LetwpRoQA1P/5eqfjyt4XoP3rFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PrRNaStGCnBFTshNjJ/LcYL+Ha3OoiTXQbGhN3vTgAfZGf3ZxWA0JDTFB1yiOtv3fM PCtMyFl1T0yFOruccZ+diU9Kp2SPaX1/G98DSQKajmxkaiuSFmw5tpOfiG8zvpB3QoGH nkeEg/yV4nErnRlbnkKab5AtOVJngQyPCSV9w= MIME-Version: 1.0 Received: by 10.91.20.12 with SMTP id x12mr2205661agi.100.1301161928939; Sat, 26 Mar 2011 10:52:08 -0700 (PDT) Received: by 10.90.100.10 with HTTP; Sat, 26 Mar 2011 10:52:08 -0700 (PDT) In-Reply-To: <20110325075541.GA1742@garage.freebsd.pl> References: <20110325075541.GA1742@garage.freebsd.pl> Date: Sat, 26 Mar 2011 10:52:08 -0700 Message-ID: From: Freddie Cash To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Filesystems , FreeBSD-Current , FreeBSD Stable Subject: Re: Any success stories for HAST + ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:52:11 -0000 On Fri, Mar 25, 2011 at 12:55 AM, Pawel Jakub Dawidek wro= te: > On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: >> I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28 >> patches, and 9-CURRENT (after the ZFSv28 commit). =C2=A0Things work well >> until I start hastd. =C2=A0Then either the system locks up, or hastd cau= ses >> a kernel panic, or hastd dumps core. > > The minimum amount of information (as always) would be backtrace from > the kernel and also hastd backtrace when it coredumps. There is really > decent logging in hast, so I'm also sure it does log something > interesting on primary or secondary. Another useful thing would be to > turn on debugging in hast (single -d option for hastd). > > The best you can do is to give me the simplest and quickest procedure to > reproduce the issue, eg. configure two hast resources, put ZFS mirror on > top, start rsync /usr/src to the file system on top of hast and switch > roles. The simpler the better. FreeBSD 8-STABLE r219754 with the ZFSv28 patches applied. hast.conf: resource disk-a1 { local /dev/label/disk-a1 on omegadrive { remote tcp4://10.20.0.102 } on alphadrive { remote tcp4://10.20.0.101 } } resource disk-a2 { local /dev/label/disk-a2 on omegadrive { remote tcp4://10.20.0.102 } on alphadrive { remote tcp4://10.20.0.101 } } Following will crash hastd: service hastd onestart hastctl create disk-a1 hastctl create disk-a2 hastctl role primary all hastd backtrace is here: http://www.sd73.bc.ca/downloads/crash/hast-backtrace.png I'll try running it with -d to see if there's anything interesting there. Sure, running it with -d and -F, output to a log file, everything works well using 2 disks. Hrm, running it with all 24 disks, I can't make it crash now. However, I did change the kernel hz from 100 to 1000. I'll see if I can switch it back to 100 and try the tests again using -dF. The backtrace listed above is with kern.hz=3D100. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 21:27:16 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B6F106566B for ; Sat, 26 Mar 2011 21:27:16 +0000 (UTC) (envelope-from josef.karthauser@unitedlane.com) Received: from k2smtpout05-01.prod.mesa1.secureserver.net (k2smtpout05-01.prod.mesa1.secureserver.net [64.202.189.56]) by mx1.freebsd.org (Postfix) with SMTP id 46EEC8FC0C for ; Sat, 26 Mar 2011 21:27:16 +0000 (UTC) Received: (qmail 30627 invoked from network); 26 Mar 2011 21:00:36 -0000 Received: from unknown (HELO ip-72.167.34.38.ip.secureserver.net) (72.167.34.38) by k2smtpout05-01.prod.mesa1.secureserver.net (64.202.189.56) with ESMTP; 26 Mar 2011 21:00:36 -0000 Received: (qmail 360 invoked from network); 26 Mar 2011 17:00:01 -0400 Received: from hoibutt.com (HELO ?90.155.77.76?) (90.155.77.76) by hoibutt.com with (AES128-SHA encrypted) SMTP; 26 Mar 2011 17:00:01 -0400 From: Dr Josef Karthauser Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Mar 2011 20:59:39 +0000 To: freebsd-fs@freebsd.org Message-Id: <9CF23177-92D6-40C5-8C68-B7E2F88236E6@unitedlane.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: ZFS Problem - full disk, can't recover space :(. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:27:16 -0000 Help! Foolishly I let my ZFS system run out of disk space. I've removed the = errant logs, but the space has not been returned. Not sure why. There = are no snapshots, and I've even desperately rebooted the machine, but = the space is still lost. # zfs list void/store NAME USED AVAIL REFER MOUNTPOINT void/store 57.2G 2.3G 57.2G /store # du -hs /store 34G /store Any idea on were the 23G has gone, or how I pursuade the zpool to return = it? Why is the filesystem referencing storage that isn't being used? To confirm, there are no snapshots here, so there shouldn't be anything = referencing that data. When I found the machine it had 0 available, but = I've found the 2.3G by removing some other files. Not sure why some = should hand the space back whilst others done. This is a bit of an emergency for me, so I'd really appreciate a quick = response if anyone knows! Many thanks, Joe p.s. this is FreeBSD 8.2 with ZFS pool version 15.= From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 21:46:51 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A57FF106564A for ; Sat, 26 Mar 2011 21:46:51 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 64CA28FC17 for ; Sat, 26 Mar 2011 21:46:51 +0000 (UTC) Received: from outgoing.leidinger.net (p5B15623C.dip.t-dialin.net [91.21.98.60]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id AAB95844015; Sat, 26 Mar 2011 22:46:46 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 0E5E6159E; Sat, 26 Mar 2011 22:46:44 +0100 (CET) Date: Sat, 26 Mar 2011 22:46:44 +0100 From: Alexander Leidinger To: Anders Andersson Message-ID: <20110326224644.00006d6b@unknown> In-Reply-To: References: X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: AAB95844015.AF0D7 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301780807.59233@8+JZ+t5kJ9C7kZNYwi07oQ X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: RAID-Z in a disk-failure. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:46:51 -0000 On Sat, 26 Mar 2011 15:42:57 +0100 Anders Andersson wrote: > Evening! I have a question about ZFS in a FreeBSD setting, more > specifically about RAID-Z. I have never used ZFS so I might have > misunderstood something, but imagine this situation: > > You're using ZFS in RAID-Z with 4 disks. One of these gets a > catastrophic failure. You replace the disk with a new one, but when > the RAID-Z is rebuilt, the software notices that one sector/block on > another disk has become corrupted. It notices this because ZFS keeps a > checksum. > > What happens then? Since the redundancy is temporarily disabled > because of the failed disk, this sector/block is nowhere to be found. > My hope is that the system will handle this gracefully, so that only > the file using this block will be unreadable, but the rest of the data > is available and can be rebuilt. The worst that could happen is that > the rebuild is refused and the whole pool is gone. > > Have I missed something in this scenario? If a corruption can not be corrected, tt's only the file (or directory-subtree) with this corruption which is unreadable. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 21:54:39 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65EB106564A for ; Sat, 26 Mar 2011 21:54:39 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 74A138FC08 for ; Sat, 26 Mar 2011 21:54:39 +0000 (UTC) Received: from outgoing.leidinger.net (p5B15623C.dip.t-dialin.net [91.21.98.60]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 23FBD844015; Sat, 26 Mar 2011 22:54:33 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 702DE159F; Sat, 26 Mar 2011 22:54:30 +0100 (CET) Date: Sat, 26 Mar 2011 22:54:30 +0100 From: Alexander Leidinger To: Dr Josef Karthauser Message-ID: <20110326225430.00006a76@unknown> In-Reply-To: <9CF23177-92D6-40C5-8C68-B7E2F88236E6@unitedlane.com> References: <9CF23177-92D6-40C5-8C68-B7E2F88236E6@unitedlane.com> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 23FBD844015.AF999 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.923, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1301781276.10259@bOWNXfUsAXJRaS+zuog5cA X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org Subject: Re: ZFS Problem - full disk, can't recover space :(. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:54:39 -0000 On Sat, 26 Mar 2011 20:59:39 +0000 Dr Josef Karthauser wrote: > Help! > > Foolishly I let my ZFS system run out of disk space. I've removed the > errant logs, but the space has not been returned. Not sure why. There > are no snapshots, and I've even desperately rebooted the machine, but > the space is still lost. > > # zfs list void/store > NAME USED AVAIL REFER MOUNTPOINT > void/store 57.2G 2.3G > 57.2G /store # du -hs /store > 34G /store > > Any idea on were the 23G has gone, or how I pursuade the zpool to > return it? Why is the filesystem referencing storage that isn't being > used? I suggest a zfs list -r -t all void/store to make really sure we/you see what we want to see. Can it be that an application has the 23G still open? > p.s. this is FreeBSD 8.2 with ZFS pool version > 15. The default setting of showing snapshots or not changed somewhere. As long as you didn't configure the pool to show snapshots (zpool get listsnapshots ), they are not shown by default. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137