From owner-freebsd-fs@FreeBSD.ORG Sun Apr 18 23:42:25 2010 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 ADBC7106566B for ; Sun, 18 Apr 2010 23:42:25 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8458FC08 for ; Sun, 18 Apr 2010 23:42:24 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas06p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100418234223.ULFN18201.nschwmtas06p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Sun, 18 Apr 2010 23:42:23 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100418234222.UAKA2131.nschwotgx02p.mx.bigpond.com@duncan.reilly.home> for ; Sun, 18 Apr 2010 23:42:22 +0000 Date: Mon, 19 Apr 2010 09:42:22 +1000 From: Andrew Reilly To: freebsd-fs@freebsd.org Message-ID: <20100418234222.GB4620@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Sun, 18 Apr 2010 23:42:22 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.4BCB98DF.0013,ss=1,fgs=0 X-SIH-MSG-ID: qh43F9z+TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rANv1RsM6kxD9EJhiGNGUiaa7nTY3Rs9mK Subject: Reliable panic: dump -L on a gjournalled file system 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, 18 Apr 2010 23:42:25 -0000 Hi all, I finally got jack of waiting for fsck on my large-ish /usr partition, so the weekend before last I re-organized my disks so that I have all of my "big" partitions gjournalled. Ever since then I've woken in the morning to discover my system hung and unresponsive, and the nightly backup not done. This weekend I went to run the backup manually, and I did it from the text console, rather than the GUI, so that I could see any last gasps from the system. And lo: it did panic. (Note to self: having the kernel set to fall into DDB on panic isn't a good idea when running an X11 workstation because once the kernel is waiting for user input on the non-visible VGA console screen, all is lost.) Anyway, here's what the panic said: panic: Journal overflow (joffset=982329115136 active=982329273344 inactive=892328975360) cpuid=1 KDB: enter: panic [thread 15 tid 100049] Stopped at kdb_enter+0x3d: moveq $0,0x6ba080(%rip) > where kdb_enter() panic() g_journal_flush() g_journal_worker() fork_exit() fork_trampoline() I thought: a-ha! dump must be such a high data-rate process that I'm overfilling the journal before it can catch itself, so I re-formatted my backup drive without a journal and tried again. Same panic. So my conclusion is that the failure is coming from the journal of the file system that I'm *dumping*, rather than the target, and is caused by the file system checkpoint produced with the -L argument to dump. I tested that theory yesterday by successfully doing a backup from single-user mode with the /usr file system off-line and no -L argument to dump. Is this just pilot error, or a known problem with gjournal? How is everyone else dumping their journalled file systems? I have another question to ask about gjournal, but I'll ask it in another message... Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Sun Apr 18 23:54:32 2010 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 F223D106566B for ; Sun, 18 Apr 2010 23:54:31 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas02p.mx.bigpond.com (nschwmtas02p.mx.bigpond.com [61.9.189.140]) by mx1.freebsd.org (Postfix) with ESMTP id 807558FC08 for ; Sun, 18 Apr 2010 23:54:30 +0000 (UTC) Received: from nschwotgx01p.mx.bigpond.com ([124.188.161.100]) by nschwmtas02p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100418235429.QIQB28300.nschwmtas02p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Sun, 18 Apr 2010 23:54:29 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20100418235428.HHAA3673.nschwotgx01p.mx.bigpond.com@duncan.reilly.home> for ; Sun, 18 Apr 2010 23:54:28 +0000 Date: Mon, 19 Apr 2010 09:54:28 +1000 From: Andrew Reilly To: freebsd-fs@freebsd.org Message-ID: <20100418235428.GC4620@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx01p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Sun, 18 Apr 2010 23:54:28 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4BCB9BB5.0047,ss=1,fgs=0 X-SIH-MSG-ID: qR4zFtL/TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rANv1RsM6kxD9EJhiGNGQkaa7tTY3Rs9mK Subject: gjournal: what is it good for? 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, 18 Apr 2010 23:54:32 -0000 So, I've had quite a bit of yoyo-mode over the last week, caused by the journal overflow panic that I reported in the previous message, and I've noticed that my gjournalled file systems do not (ever) mark themselves clean after the journal is replayed, and so still require fsck, which takes just as long as it ever did. I assume that the journals have been replayed, because after these crashes I've had to sit through screen-fulls of "Root mount waiting for: GJOURNAL" messages, even though my root partition is not gjournalled. Is that assumption correct? Even after that waiting (which has been on the order of ten minutes or so), an attempt to mount one of my journalled partitions results in a message like: Warning: R/W mount of /usr denied. Filesystem is not clean - run fsck. mount: /dev/mirror/gm0e.journal: operation not permitted. So: if a manual fsck is required before mounting a journalled partition after a crash, what purpose does the journalling serve? Clearly I'm doing something wrong here: I've read no other messages suggesting that gjournal is totally useless, but what? All of my gjournal partitions have been set up according to the examples in the man page, and the newfs operations that followed all had the -J option, also per the man page. They're all mounted async, per the man page. Here's my current df state: Filesystem Size Used Avail Capacity Mounted on /dev/mirror/gm0a 2.1G 550M 1.4G 29% / devfs 1.0k 1.0k 0B 100% /dev /dev/mirror/gm0d 10G 248M 9.3G 3% /var /dev/mirror/gm0e.journal 951G 296G 578G 34% /usr /dev/ad10s1.journal 726G 226G 442G 34% /nb procfs 4.1k 4.1k 0B 100% /proc /dev/md0 65M 35k 60M 0% /tmp /dev/ad8s1a.journal 1.5T 692G 644G 52% /mnt /dev/da0s1a 969G 296G 595G 33% /backup and my /etc/fstab: # Device Mountpoint FStype Options Dump Pass# /dev/ad4s1b none swap sw 0 0 /dev/ad6s1b none swap sw 0 0 /dev/mirror/gm0a / ufs rw 1 1 /dev/mirror/gm0d /var ufs rw 1 2 /dev/mirror/gm0e.journal /usr ufs rw,async 1 3 /dev/ad10s1.journal /nb ufs rw,async 0 2 /dev/ad8s1a.journal /mnt ufs rw,async,noauto 0 2 /dev/da0s1a /backup ufs rw,async,noauto 0 2 proc /proc procfs rw 0 0 #linprocfs /compat/linux/proc linprocfs rw 0 0 (/backup used to be on a journal too, but I removed that when I attempted to sort out the panic-on-dump problem.) Oh: I'm running 9-current as of this weekend. Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Mon Apr 19 05:42:32 2010 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 1FCE3106564A; Mon, 19 Apr 2010 05:42:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB6418FC0C; Mon, 19 Apr 2010 05:42:31 +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 o3J5gVb8029142; Mon, 19 Apr 2010 05:42:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3J5gV1r029138; Mon, 19 Apr 2010 05:42:31 GMT (envelope-from linimon) Date: Mon, 19 Apr 2010 05:42:31 GMT Message-Id: <201004190542.o3J5gV1r029138@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/145802: [zfs] page fault under load 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, 19 Apr 2010 05:42:32 -0000 Synopsis: [zfs] page fault under load Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 19 05:42:22 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=145802 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 19 11:06:58 2010 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 CF4A71065676 for ; Mon, 19 Apr 2010 11:06:58 +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 A488F8FC25 for ; Mon, 19 Apr 2010 11:06:58 +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 o3JB6wm6034087 for ; Mon, 19 Apr 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3JB6wZU034085 for freebsd-fs@FreeBSD.org; Mon, 19 Apr 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Apr 2010 11:06:58 GMT Message-Id: <201004191106.o3JB6wZU034085@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, 19 Apr 2010 11:06:58 -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/145802 fs [zfs] page fault under load o kern/145778 fs [zfs] [panic] panic in zfs_fuid_map_id (known issue fi o kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145424 fs [zfs] [patch] move source closer to v15 o kern/145423 fs [zfs] ZFS/zpool status shows deleted/not present pools o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an o kern/145339 fs [zfs] deadlock after detaching block device from raidz o kern/145309 fs [disklabel]: Editing disk label invalidates the whole 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 o kern/144458 fs [nfs] [patch] nfsd fails as a kld 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/144330 fs [nfs] mbuf leakage in nfsd with zfs o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o bin/144214 fs zfsboot fails on gang block after upgrade to zfs v14 o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o kern/143345 fs [ext2fs] [patch] extfs minor header cleanups to better o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142924 fs [ext2fs] [patch] Small cleanup for the inode struct in 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/140433 fs [zfs] [panic] panic while replaying ZIL after 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 o 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/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr 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 o 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/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w 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/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv 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/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour 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 p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz 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/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t 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] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B 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 mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N 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/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex 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] mount_msdosfs: msdosfs_iconv: Operation not 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 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic 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 f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in 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/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi 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 kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi 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 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/53137 fs [ffs] [panic] background fscking causing ffs_valloc pa 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 kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 174 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 19 12:48:47 2010 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 E4FD61065673; Mon, 19 Apr 2010 12:48:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6338FC14; Mon, 19 Apr 2010 12:48:46 +0000 (UTC) Received: by wyf28 with SMTP id 28so1173267wyf.13 for ; Mon, 19 Apr 2010 05:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=bbOc2fg6xyfor9Mw/sbhf05lFMFhfSMmZZUMg9lZ0eI=; b=VTVVqLbJ1FJLMKebd4FsOQY5m5MkZ0cMi+sxW6oxQY+jT6otd0qcr1t0fNG1YX8AtY I1rtD3PL3WFCnMES9QdZOs5gxO5++KTBnc57ruuafl2q6LGvRGXM9ccQVx00ICGZsWKf hojrFaDxZS3lI0bn+ShmMgQxS4uLR3p/Lt/jM= 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=thtbG7bq+o1K5iGESXLOYvIy/RY1SuS90kUgi3+G9BhFvIzn3tpMxaFLC89iOjrNQr w6L89+honznYpk05sEmhq3ca0SJ4Z7gpn8xfuFgN6fhRF05jjydfQ1/Bwbwsdmv828Kr YmXGtMs0O//EidUSFlLHPftbekBY/DsK5B1V4= MIME-Version: 1.0 Received: by 10.216.49.76 with HTTP; Mon, 19 Apr 2010 05:48:45 -0700 (PDT) In-Reply-To: References: <4BC9E254.9070300@freebsd.org> Date: Mon, 19 Apr 2010 12:48:45 +0000 Received: by 10.216.156.209 with SMTP id m59mr978871wek.105.1271681325994; Mon, 19 Apr 2010 05:48:45 -0700 (PDT) Message-ID: From: Paul B Mahol To: Tim Kientzle Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs 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, 19 Apr 2010 12:48:48 -0000 On 4/17/10, Paul B Mahol wrote: > On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle wrote: >> Paul B Mahol wrote: >>> >>> It is apparently not possible to make use of -use-the-force-luke=4gms >>> on FreeBSD when appending new session after 4GB. Mounted disk >>> afterwards show nothing. >>> >>> Should we allow it like linux does? >> >> Are you claiming there is a problem when FreeBSD reads such >> images or a problem with creating such images? What >> programs are you using? > > I burn flac files in multiple sessions, each session have separate > directory, on DVD+R DL MKM/003 > After I used 4gms switch mounted fs shows nothing. (but there is >5GB of > data) > > According to growisofs source BD (bluray) dont need this switch at all ... > >> This sounds like a pretty unsurprising 32-bit truncation >> bug: the filesystem structures in ISO9660 are all sector >> numbers so 8TB should be the natural limit (4G sectors >> times 2k bytes/sector). > > I did not tested this on FreeBSD amd64 yet. Update: Linux shows all sessions and Windows 7 shows only first one. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 19 13:58:51 2010 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 5DD41106566C; Mon, 19 Apr 2010 13:58:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2886C8FC14; Mon, 19 Apr 2010 13:58:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA28335; Mon, 19 Apr 2010 16:58:48 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BCC6198.4020808@icyb.net.ua> Date: Mon, 19 Apr 2010 16:58:48 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Tim Kientzle References: <4BC9E254.9070300__39016.1050054759$1271523997$gmane$org@freebsd.org> In-Reply-To: <4BC9E254.9070300__39016.1050054759$1271523997$gmane$org@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs 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, 19 Apr 2010 13:58:51 -0000 on 17/04/2010 19:31 Tim Kientzle said the following: > Paul B Mahol wrote: >> >> It is apparently not possible to make use of -use-the-force-luke=4gms >> on FreeBSD when appending new session after 4GB. Mounted disk >> afterwards show nothing. >> >> Should we allow it like linux does? > > Are you claiming there is a problem when FreeBSD reads such > images or a problem with creating such images? What > programs are you using? > > This sounds like a pretty unsurprising 32-bit truncation > bug: the filesystem structures in ISO9660 are all sector > numbers so 8TB should be the natural limit (4G sectors > times 2k bytes/sector). I don't think that the problem is with limit on sector count here. I think it's a limitation with size/offset in bytes somewhere in cd9660 fs driver. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Apr 19 14:42:08 2010 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 127E2106566C; Mon, 19 Apr 2010 14:42:07 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED8F8FC1B; Mon, 19 Apr 2010 14:42:05 +0000 (UTC) Received: by ewy24 with SMTP id 24so1413040ewy.33 for ; Mon, 19 Apr 2010 07:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OvTdHNiGqa5q64ElbWtUWOjJPVFzyq4wz+xGbqGlDGU=; b=jiVp3p0CAoiCbyy4qdS8uWHzpjCpsTTzN7AOA2IQfDxSovmk2sRWnQAgqyw1abFrnM Cckuuzicr9Dtxc0WZ9Nz2k/sTBmkIkUV3j3SYvwiRt0zrikevMlNHdgph3NY2oCi29Cw oGUJvld0RxhBfnplamZT2tyQ29V+vBlmWtQJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NgbTJBMD+ExRkSEJZCmOCiCEl+FWn4HTXl54PWbVbYkW3WFqaxIhySbBo10gWW1LMo kJSDD3fyGETXBj9CQrxM8XUK7nssPH//Obc66+oCVsxeN5CWF+g5vRj9Tjt9riPVA309 K5GNBDwCxudz/0GqxGsAnupZCDY8/S6h/8Yow= MIME-Version: 1.0 Received: by 10.239.142.17 with HTTP; Mon, 19 Apr 2010 07:10:39 -0700 (PDT) In-Reply-To: References: <4BC9E254.9070300@freebsd.org> Date: Mon, 19 Apr 2010 15:10:39 +0100 Received: by 10.239.165.138 with SMTP id x10mr512493hbd.148.1271686239293; Mon, 19 Apr 2010 07:10:39 -0700 (PDT) Message-ID: From: Tom Evans To: Paul B Mahol Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Tim Kientzle , current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs 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, 19 Apr 2010 14:42:08 -0000 On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol wrote: > On 4/17/10, Paul B Mahol wrote: >> On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle wro= te: >>> Paul B Mahol wrote: >>>> >>>> It is apparently not possible to make use of -use-the-force-luke=3D4gm= s >>>> on FreeBSD when appending new session after 4GB. Mounted disk >>>> afterwards =C2=A0show nothing. >>>> >>>> Should we allow it like linux does? >>> >>> Are you claiming there is a problem when FreeBSD reads such >>> images or a problem with creating such images? =C2=A0What >>> programs are you using? >> >> I burn flac files in multiple sessions, each session have separate >> directory, on DVD+R DL MKM/003 >> After I used 4gms switch mounted fs shows nothing. (but there is >5GB of >> data) >> >> According to growisofs source BD (bluray) dont need this switch at all .= .. >> >>> This sounds like a pretty unsurprising 32-bit truncation >>> bug: =C2=A0the filesystem structures in ISO9660 are all sector >>> numbers so 8TB should be the natural limit (4G sectors >>> times 2k bytes/sector). >> >> I did not tested this on FreeBSD amd64 yet. > > Update: Linux shows all sessions and Windows 7 shows only first one. >From the source code of groisofs.c: * - DVD+R Double Layer support; * - -use-the-force-luke=3D4gms to allow ISO9660 directory structures * to cross 4GB boundary, the option is effective only with DVD+R DL * and for data to be accessible under Linux isofs a kernel patch is * required; So I'm guessing it does something non standard, particularly if windows also refuses to see the data. Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Mon Apr 19 15:18:32 2010 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 0CDF31065674; Mon, 19 Apr 2010 15:18:32 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 48BCC8FC13; Mon, 19 Apr 2010 15:18:30 +0000 (UTC) Received: by wyf28 with SMTP id 28so1292944wyf.13 for ; Mon, 19 Apr 2010 08:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=W/f1KBV5ZbL653ThziCf+JyE1m+QMOXcOLzbANKBCBU=; b=tLBR/dXSsXjefI8rvAUKf01JCBlW6aP5aXY16OfiT5l3VVEmyitRIMPpLCLEJ99wWc LnvAwNvlFcr20j024cveP4UMSrfoLsoAcFOYE6eimmZmfErSCaKdUi62G9lL0GBK3zIt Y3GIQwFnfJxuzRB3yvOAbuwHxMrik+MIKvFBs= 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=PHN7h59KnxXCrnUmbA4a0K1XEEZ/kQ2XgIuHrvqt2b527WlJscchKJhd0CVZne/R6E o17F4pRhq46j5ka+UNRPp8Ll1aySgu6xx9X60UQKzy3Lq8SM9Pia3Yf16iNzsU6+OEQO TPRaFHjnuRqsIH04fM/aSVRtKwddSc9MyR5Eo= MIME-Version: 1.0 Received: by 10.216.49.76 with HTTP; Mon, 19 Apr 2010 08:18:29 -0700 (PDT) In-Reply-To: References: <4BC9E254.9070300@freebsd.org> Date: Mon, 19 Apr 2010 15:18:29 +0000 Received: by 10.216.88.148 with SMTP id a20mr3113743wef.124.1271690309913; Mon, 19 Apr 2010 08:18:29 -0700 (PDT) Message-ID: From: Paul B Mahol To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: Tim Kientzle , current@freebsd.org, fs@freebsd.org Subject: Re: ISO9660 4GB directory structures boundary limit and growisofs 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, 19 Apr 2010 15:18:32 -0000 On 4/19/10, Tom Evans wrote: > On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol wrote: >> On 4/17/10, Paul B Mahol wrote: >>> On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle >>> wrote: >>>> Paul B Mahol wrote: >>>>> >>>>> It is apparently not possible to make use of -use-the-force-luke=4gms >>>>> on FreeBSD when appending new session after 4GB. Mounted disk >>>>> afterwards show nothing. >>>>> >>>>> Should we allow it like linux does? >>>> >>>> Are you claiming there is a problem when FreeBSD reads such >>>> images or a problem with creating such images? What >>>> programs are you using? >>> >>> I burn flac files in multiple sessions, each session have separate >>> directory, on DVD+R DL MKM/003 >>> After I used 4gms switch mounted fs shows nothing. (but there is >5GB of >>> data) >>> >>> According to growisofs source BD (bluray) dont need this switch at all >>> ... >>> >>>> This sounds like a pretty unsurprising 32-bit truncation >>>> bug: the filesystem structures in ISO9660 are all sector >>>> numbers so 8TB should be the natural limit (4G sectors >>>> times 2k bytes/sector). >>> >>> I did not tested this on FreeBSD amd64 yet. >> >> Update: Linux shows all sessions and Windows 7 shows only first one. > > > From the source code of groisofs.c: > > * - DVD+R Double Layer support; > * - -use-the-force-luke=4gms to allow ISO9660 directory structures > * to cross 4GB boundary, the option is effective only with DVD+R DL > * and for data to be accessible under Linux isofs a kernel patch is > * required; > > So I'm guessing it does something non standard, particularly if > windows also refuses to see the data. That is pretty old, from 2.4 era, it was added after it was found that isofs had bug. Windows at least "try" to show something - only one session, but fourth and not second session crossed 4GB limit. The source also claims that in BD case there is no need for _force_ switch at all. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 06:07:38 2010 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 0B8EC106564A for ; Tue, 20 Apr 2010 06:07:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 97D9A8FC08 for ; Tue, 20 Apr 2010 06:07:37 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0B60445D8D; Tue, 20 Apr 2010 08:07:35 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1A2F445CA6; Tue, 20 Apr 2010 08:07:30 +0200 (CEST) Date: Tue, 20 Apr 2010 08:07:32 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100420060731.GD1728@garage.freebsd.pl> References: <20100416065126.GG1705@garage.freebsd.pl> <4BCD3979.8050107@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fXStkuK2IQBfcDe+" Content-Disposition: inline In-Reply-To: <4BCD3979.8050107@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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: Tue, 20 Apr 2010 06:07:38 -0000 --fXStkuK2IQBfcDe+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2010 at 02:19:53PM +0900, hiroshi@soupacific.com wrote: > Hi ! >=20 > I try to check HAST on test servers, and got folowing error. >=20 > #hastctl role init test >=20 > then > [ERROR] Unable to coonect to hastd via /var/run > I tried > ln -s /sbin/hastctl /var/run > then error is > hastctl: socket operation on non-socket >=20 > Do you have any idea what I made wrong? Is hastd daemon running? Take a look at: http://wiki.freebsd.org/HAST There is a section describing how to initialize HAST starting with: "Before we start ucarp.sh we have to do some initializations:" --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --fXStkuK2IQBfcDe+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvNRKMACgkQForvXbEpPzTcHQCfe+fnqo5FIgU0U70eZGDvo2Ky sBkAoMqkLYC2oWfCvrEt6Fea/8uu/7ZP =Djpz -----END PGP SIGNATURE----- --fXStkuK2IQBfcDe+-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 09:47:15 2010 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 5EA70106566B for ; Tue, 20 Apr 2010 09:47:15 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id A53ED8FC1F for ; Tue, 20 Apr 2010 09:47:14 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 74BE245DF4; Tue, 20 Apr 2010 11:47:12 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id AA23345C8C; Tue, 20 Apr 2010 11:47:07 +0200 (CEST) Date: Tue, 20 Apr 2010 11:47:11 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100420094711.GB1691@garage.freebsd.pl> References: <20100416065126.GG1705@garage.freebsd.pl> <4BCD3979.8050107@soupacific.com> <4BCD5AD7.8070502@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: <4BCD5AD7.8070502@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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: Tue, 20 Apr 2010 09:47:15 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2010 at 04:42:15PM +0900, hiroshi@soupacific.com wrote: > Sorry for my first email. >=20 > [ERROR] Unable to coonect to hastd via /var/run > this error is lloking for directory ! >=20 > Still error is same > hastctl: socket operation on non-socket >=20 > Any idea ? Could you provide your hast.conf for starters? PS. Fix your mail server. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvNeB4ACgkQForvXbEpPzRQTQCgsOFjEt9nzTEdcPpKJDre/LK5 0uEAnjdRmSj61Snzc56PiybfnaDHhnRG =qZ+/ -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 13:50:09 2010 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 55D091065672 for ; Tue, 20 Apr 2010 13:50:09 +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 44B788FC1A for ; Tue, 20 Apr 2010 13:50:09 +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 o3KDo8xa004417 for ; Tue, 20 Apr 2010 13:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3KDo8LG004409; Tue, 20 Apr 2010 13:50:08 GMT (envelope-from gnats) Date: Tue, 20 Apr 2010 13:50:08 GMT Message-Id: <201004201350.o3KDo8LG004409@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andrey Simonenko Cc: Subject: Re: kern/136865: NFS exports atomic and on-the-fly atomic updates X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Simonenko List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 13:50:09 -0000 The following reply was made to PR kern/136865; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/136865: NFS exports atomic and on-the-fly atomic updates Date: Tue, 20 Apr 2010 16:44:44 +0300 New version nfse-20100420 was released. It has several improvements, most important of them are given here. There are two new options -subdir and -alldirs in nfs.exports(5), that allow to specify administrative subdirectories exports for NFSv2 and NFSv3 clients. There is new option -C for the nfse utility, that turns on compatible mode with the mountd(8) utility and its configuration file exports(5). Now the NFSE code is aware that a file system mount point directory can be renamed. Now WebNFS settings can be updated by "nfse -c ..." commands and are shown in the "nfse -c show" command's output. New version can be downloaded from http://nfse.sourceforge.net/ From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 14:24:45 2010 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 40287106566B for ; Tue, 20 Apr 2010 14:24:45 +0000 (UTC) (envelope-from davide.damico@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id C85188FC1B for ; Tue, 20 Apr 2010 14:24:44 +0000 (UTC) Received: by bwz8 with SMTP id 8so5601940bwz.3 for ; Tue, 20 Apr 2010 07:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=h6FnVXDkU7RMpIqN+d22NXuOHphpQXiTnanimVft7so=; b=rBMtshNL1bdnaZ1lD5xCP7xQs7+6NXiV7FMs+N9iJw05+KqEV6b5ANh6kbicxx0OWe Ta/A3obvwgagzNIZAWYBFsozgGNswDT+5C/kuQ6Z3oGE5t9daLa350U4OqxDLmGbN/9V KXtubz1zXemAREezivECQ/Knnev2AXjJZTFJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ArmrPKRoiCQHv6K7CmxZ7lfti2sdwFQt8r8yWaQiyB1JMi3gLmxtpnzOaTNXheRAoo W27S+lAKqtbHVI5CGg6o0arvHeIxuRODKut4p18kl9beIxaq9SPvWVgPkSdfVq2wuHzP Zxk0GOwYn7OolFVbIo6nMQRmgoksXStY3FO/s= MIME-Version: 1.0 Received: by 10.204.121.129 with HTTP; Tue, 20 Apr 2010 07:24:22 -0700 (PDT) From: "Davide D'Amico" Date: Tue, 20 Apr 2010 16:24:22 +0200 Received: by 10.204.25.209 with SMTP id a17mr471189bkc.28.1271773483536; Tue, 20 Apr 2010 07:24:43 -0700 (PDT) Message-ID: To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: HAST and 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: Tue, 20 Apr 2010 14:24:45 -0000 Hi, I'm trying to setup an active/passive cluster. Some questions: - why the use of net/ucarp rather than carp? Is it for its up/down scripts? - I would like to use ZFS on top on HAST, so I think that in wiki.freebsd.org/HAST I should change UFS (in sh scripts) but how to replace newfs command? With zpool create disk da0? Thanks for your work, -- d. From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 14:39:45 2010 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 7303D106564A for ; Tue, 20 Apr 2010 14:39:45 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pz0-f201.google.com (mail-pz0-f201.google.com [209.85.222.201]) by mx1.freebsd.org (Postfix) with ESMTP id 4864A8FC0C for ; Tue, 20 Apr 2010 14:39:44 +0000 (UTC) Received: by pzk39 with SMTP id 39so4188058pzk.7 for ; Tue, 20 Apr 2010 07:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=8bNgdM5jrYQPY58eZnv75Ta73jZFeNqXC6E58h8iHTo=; b=OhUeAKgc9IFUblLyNC8UIhyL7AGUOCRfd3UCYMtUCkVS1IiJhAgXPZAaHauYPrWEAp tz3lHt5Wbgsyn1edkfHSPhNvKvg4cWIGETYbDugYwJuvsuFSnGBUmS6IhoOPNjPxUNjc uuovnxWyJIF9vUEnpt1BitjqHMswRusiqrBXc= 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=I/+RE11NtsEAn+gEFNVoHbARFLtCjj94QWM6eRcJwILQHM80GpcSW3yY2tkIVQhaqK PI9IZId2amOntsXULdtZ5ROEgXb9ylsYDgqU09srrvBMfflvBN74rfA49cyiQABE8V7C erR7B75dMVmcjx6sxtxBq10/D3lCBfxkLpVss= MIME-Version: 1.0 Received: by 10.231.18.74 with HTTP; Tue, 20 Apr 2010 07:39:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Apr 2010 07:39:43 -0700 Received: by 10.140.57.8 with SMTP id f8mr5769686rva.102.1271774384395; Tue, 20 Apr 2010 07:39:44 -0700 (PDT) Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: HAST and 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: Tue, 20 Apr 2010 14:39:45 -0000 On Tue, Apr 20, 2010 at 7:24 AM, Davide D'Amico wrote: > I'm trying to setup an active/passive cluster. > Some questions: > - why the use of net/ucarp rather than carp? Is it for its up/down scripts? > - I would like to use ZFS on top on HAST, so I think that in > wiki.freebsd.org/HAST > I should change UFS (in sh scripts) but how to replace newfs command? > With zpool create disk da0? > See the mailing list archives. I posted a devd.conf and script for using CARP instead of uCARP, for using HAST devices to create a ZFS pool. Works quite nicely, although there are no checks/fixes to prevent split-brain if CARP flip-flops between the two hosts. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 20:45:45 2010 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 58359106568B for ; Tue, 20 Apr 2010 20:45:45 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id CE4208FC16 for ; Tue, 20 Apr 2010 20:45:44 +0000 (UTC) Received: from furia.intranet ([188.174.66.31]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, SSL: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.yellowspace.net with esmtp; Tue, 20 Apr 2010 22:45:41 +0200 id 0036A149.000000004BCE1275.00014483 Message-ID: <4BCE1274.1070903@yellowspace.net> Date: Tue, 20 Apr 2010 22:45:40 +0200 From: Lorenzo Perone User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: HAST: question about secondary outage time 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: Tue, 20 Apr 2010 20:45:45 -0000 Hello, Welcome to HAST in 8/stable! Happy to see it around. The manual states..: > When primary hastd is unable to connect or connection fails, > it will try to re-establish connection every few seconds. > Once connection is established, primary hastd will synchronize > every extent that was modified during connection outage > to the secondary hastd. Question: For how long can a secondary be offline before a full synchronisation becomes necessary? In other words, on which resources and/or tunables does this depend upon? Great work pjd, I guess we're all big fans of all your GEOMs, and this is a welcome new one :) big Regards, Lorenzo From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 23:44:54 2010 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 238FF1065670 for ; Tue, 20 Apr 2010 23:44:54 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6745C8FC19 for ; Tue, 20 Apr 2010 23:44:52 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5E83F45C8C; Wed, 21 Apr 2010 01:44:51 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 33CF745685; Wed, 21 Apr 2010 01:44:46 +0200 (CEST) Date: Wed, 21 Apr 2010 01:44:47 +0200 From: Pawel Jakub Dawidek To: Andrew Reilly Message-ID: <20100420234447.GB1737@garage.freebsd.pl> References: <20100418235428.GC4620@duncan.reilly.home> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <20100418235428.GC4620@duncan.reilly.home> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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: Tue, 20 Apr 2010 23:44:54 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2010 at 09:54:28AM +1000, Andrew Reilly wrote: > So, I've had quite a bit of yoyo-mode over the last week, caused > by the journal overflow panic that I reported in the previous > message, and I've noticed that my gjournalled file systems do > not (ever) mark themselves clean after the journal is replayed, > and so still require fsck, which takes just as long as it ever > did. When gjournal is in use, fsck is still needed, indeed, but only to fix one type of inconsistencies: orphaned files. This is something we cannot do without fsck. Still such fsck should be much, much faster. There are various optimizations that allow to stop fsck as soon as we fix last orphaned file. If there are no such files, we won't even scan single cylinder group. We observed fsck time to drop from 8h to few seconds, so something must be wrong with your configuration if it takes as much time as without gjournal. You can still run full fsck on gjournaled file system, of course, but in regular use, 'fsck_ffs -p' should perform fast fsck. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvOPG8ACgkQForvXbEpPzSNigCdE1OsXxLfe5H+z8yaA0VyaWmq J2oAoKMaDtsqCNqxlz/HJ/LcMwBSPSIk =15NY -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-fs@FreeBSD.ORG Tue Apr 20 23:49:04 2010 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 2FC74106566B for ; Tue, 20 Apr 2010 23:49:04 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 734838FC2C for ; Tue, 20 Apr 2010 23:49:03 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9D1A945E8F; Wed, 21 Apr 2010 01:49:01 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 753BE45E82; Wed, 21 Apr 2010 01:48:56 +0200 (CEST) Date: Wed, 21 Apr 2010 01:48:58 +0200 From: Pawel Jakub Dawidek To: Lorenzo Perone Message-ID: <20100420234858.GC1737@garage.freebsd.pl> References: <4BCE1274.1070903@yellowspace.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="96YOpH+ONegL0A3E" Content-Disposition: inline In-Reply-To: <4BCE1274.1070903@yellowspace.net> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST: question about secondary outage time 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: Tue, 20 Apr 2010 23:49:04 -0000 --96YOpH+ONegL0A3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2010 at 10:45:40PM +0200, Lorenzo Perone wrote: >=20 > Hello, >=20 > Welcome to HAST in 8/stable! Happy to see it around. >=20 > The manual states..: >=20 > >When primary hastd is unable to connect or connection fails, > >it will try to re-establish connection every few seconds. > >Once connection is established, primary hastd will synchronize > >every extent that was modified during connection outage > >to the secondary hastd. >=20 > Question: For how long can a secondary be offline before a > full synchronisation becomes necessary? In other words, on which=20 > resources and/or tunables does this depend upon? There is no threshold that will trigger full synchronization. If secondary if offline even for a very long time, but primary wasn't modified much during that time, it will take very short while to sync. Full synchronization if only performed when clean provider is connected or in unlikely situation when every extent becomes dirty during secondary outage. > Great work pjd, I guess we're all big fans of all your GEOMs, and this=20 > is a welcome new one :) Thank you. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --96YOpH+ONegL0A3E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvOPWkACgkQForvXbEpPzQgFgCg4f/STH8TlVDMGWh/NSXYuFJQ I2AAmwQDR7gaDt2532xw8PplqM+hEHB3 =IPi0 -----END PGP SIGNATURE----- --96YOpH+ONegL0A3E-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 01:18:38 2010 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 218D1106564A; Wed, 21 Apr 2010 01:18:38 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id 757908FC2D; Wed, 21 Apr 2010 01:18:37 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([124.188.161.100]) by nskntmtas02p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100421011835.MDWG4632.nskntmtas02p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Wed, 21 Apr 2010 01:18:35 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100421011834.KXOF1978.nskntotgx03p.mx.bigpond.com@duncan.reilly.home>; Wed, 21 Apr 2010 01:18:34 +0000 Date: Wed, 21 Apr 2010 11:18:34 +1000 From: Andrew Reilly To: Pawel Jakub Dawidek Message-ID: <20100421011834.GA24928@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100420234447.GB1737@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Wed, 21 Apr 2010 01:18:34 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4BCE526B.005F,ss=1,fgs=0 X-SIH-MSG-ID: qB8wEdz8TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRsM6kxDxNJhqENGAoaa/hTY3Rs9mK Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 01:18:38 -0000 Hi Pawel, Thanks for pointing this out! On 21/04/2010, at 09:44, Pawel Jakub Dawidek wrote: > You can still run full fsck on > gjournaled file system, of course, but in regular use, 'fsck_ffs -p' > should perform fast fsck. I think that's the problem: I had assumed that the journal replay obviated the need for fsck at all, so when mounting was refused I went straight to "fsck -y", which does a full-scan and takes just as long as it used to. Since sending that message I've been prompted to check the source and now know (!) that I still need to run fsck -p. I just haven't had any crashes in the mean-time, to give me an opportunity to try that out. If you have any clues about the journal full with dump -L issue, that'd be greatly appreciated. I'm fairly sure I could generate a crash if I put the "L" back into my backup scripts... Cheers, Andrew From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 02:20:47 2010 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 9E953106566C for ; Wed, 21 Apr 2010 02:20:47 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5450B8FC1C for ; Wed, 21 Apr 2010 02:20:47 +0000 (UTC) Received: by qyk11 with SMTP id 11so7464532qyk.13 for ; Tue, 20 Apr 2010 19:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h62GaAtFNnV8VCb07inU9XUhuwwhZoCzNIFcMCpLvhU=; b=mo4l/U/F87yGHZfqg7FyjpurOugrt9N22s+B8Y7HltCiQExYV/EoLTzmlsa3H24XbF SXceT9Nx/tPG1UqyQnLGVVoTF0MvhLpuSrTuZbzNmfZLv6hoYaBegTEl3Wuhr8aXZzm3 GlZWqv/chnii5U8OcdZRKgxj2i8XnMwRw9SVs= 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=ZF5XWRzlwEpnxQMgr4rUsrIO2OcmcqEh/xLc7wgSJ1EDU0jT2o5bWT1HWDuIfBsQYP 59sDqhZFdAfq1Aq+6Lpjr1EJBiWLlVOV9GLDNpWH97hYOJ5u0alKAYn0lMWviJs+3luf 4aC6LX8+euWo/SpjYbWt7SmqHQlG94/Fq7Rqg= MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Tue, 20 Apr 2010 19:20:46 -0700 (PDT) In-Reply-To: <20100421011834.GA24928@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> Date: Wed, 21 Apr 2010 12:20:46 +1000 Received: by 10.229.250.211 with SMTP id mp19mr3018959qcb.42.1271816446496; Tue, 20 Apr 2010 19:20:46 -0700 (PDT) Message-ID: From: David N To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 02:20:47 -0000 On 21 April 2010 11:18, Andrew Reilly wrote: > Hi Pawel, > > Thanks for pointing this out! > > On 21/04/2010, at 09:44, Pawel Jakub Dawidek wrote: >> You can still run full fsck on >> gjournaled file system, of course, but in regular use, 'fsck_ffs -p' >> should perform fast fsck. > > I think that's the problem: I had assumed that the journal > replay obviated the need for fsck at all, so when mounting was > refused I went straight to "fsck -y", which does a full-scan and > takes just as long as it used to. =A0Since sending that message > I've been prompted to check the source and now know (!) that I > still need to =A0run fsck -p. =A0I just haven't had any crashes in > the mean-time, to give me an opportunity to try that out. > > If you have any clues about the journal full with dump -L issue, > that'd be greatly appreciated. =A0I'm fairly sure I could generate > a crash if I put the "L" back into my backup scripts... > > Cheers, > > Andrew > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Gjournal on my systems are pretty quick on startup after a power outtage. What kind of disks are you using? Or what hardware are you using? Might be the disks are ignoring the BIO_FLUSH. Regards David N From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 02:24:39 2010 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 C9215106566C for ; Wed, 21 Apr 2010 02:24:39 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id A69628FC12 for ; Wed, 21 Apr 2010 02:24:39 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 44EBB439E38 for ; Tue, 20 Apr 2010 21:06:32 -0500 (CDT) Message-ID: <4BCE6B95.3010409@fuujingroup.com> Date: Tue, 20 Apr 2010 21:05:57 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: MM-5425CN nand SSD 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, 21 Apr 2010 02:24:39 -0000 Posted this to the SCSI list about a week ago, but with no responses, I suspect it should have been posted here. Sorry for cross-posting: Not sure if the NAND drivers being written at http://wiki.freebsd.org/NAND apply to this device or not. It appears this is more of a simulator at the moment and an experimental framework. Is there any current support for the MM-5425CN series NAND flash cards in FreeBSD? These seem like they'd be excellent for a separate ZIL in a ZFS raidz config if installed in pairs for mirroring... Here's the pciconf probe of the device in question: none3@pci0:6:2:0: class=0x058000 card=0x00000000 chip=0x54251332 rev=0x06 hdr=0x00 vendor = 'Micro Memory' device = 'MM-5425CN PCI 64/66 Memory Module with Battery Backup' class = memory -- Erich M. Jenkins Fuujin Group Limited (Direct) 218-251-5359 "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 02:31:48 2010 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 6273C106564A for ; Wed, 21 Apr 2010 02:31:48 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3DBB18FC0C for ; Wed, 21 Apr 2010 02:31:48 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o3L2VlFK054104 for ; Tue, 20 Apr 2010 19:31:47 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BCE63AA.3030706@feral.com> Date: Tue, 20 Apr 2010 19:32:10 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4BCE6B95.3010409@fuujingroup.com> In-Reply-To: <4BCE6B95.3010409@fuujingroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Tue, 20 Apr 2010 19:31:47 -0700 (PDT) Subject: Re: MM-5425CN nand SSD 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, 21 Apr 2010 02:31:48 -0000 On 4/20/2010 8:05 PM, Erich Jenkins, Fuujin Group Ltd wrote: > Posted this to the SCSI list about a week ago, but with no responses, > I suspect it should have been posted here. Sorry for cross-posting: (Hi, Erich!) > > Not sure if the NAND drivers being written at > http://wiki.freebsd.org/NAND apply to this device or not. It appears > this is more of a simulator at the moment and an experimental > framework. Is there any current support for the MM-5425CN series NAND > flash cards in FreeBSD? These seem like they'd be excellent for a > separate ZIL in a ZFS raidz config if installed in pairs for mirroring... > > Here's the pciconf probe of the device in question: > > none3@pci0:6:2:0: class=0x058000 card=0x00000000 chip=0x54251332 > rev=0x06 hdr=0x00 > vendor = 'Micro Memory' > device = 'MM-5425CN PCI 64/66 Memory Module with Battery Backup' > class = memory > > > This looks like the old MMI card- not NAND. It's ECC ram with a battery. It won't fit into PCI-X slots- it predates it. It has a linux driver for it. DataDomain used it in there 200 series model. NetApp used it a while back too. It has a history going back to SBus PrestoServe. I don't believe anyone has ever done a FreeBSD driver. MMI got eaten up by Curtiss Wright a year or so ago. I actually have one, but considering that the connectivity to such a card, no matter how nice, isn't worth it. I don't believe they're being built any more. Insofar as NAND drivers, you might check with the PowerPC FreeBSD port people- they've just done a bunch of changes and look like they're supporting some of the embedded stuff, which means they'll have that entire wad of NAND and NOR based device support at their fingers. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 02:45:02 2010 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 B5F251065670 for ; Wed, 21 Apr 2010 02:45:02 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id 917B78FC12 for ; Wed, 21 Apr 2010 02:45:02 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 4A14B439E38; Tue, 20 Apr 2010 21:45:28 -0500 (CDT) Message-ID: <4BCE74B5.2070506@fuujingroup.com> Date: Tue, 20 Apr 2010 21:44:53 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matthew Jacob References: <4BCE6B95.3010409@fuujingroup.com> <4BCE63AA.3030706@feral.com> In-Reply-To: <4BCE63AA.3030706@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: MM-5425CN nand SSD 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, 21 Apr 2010 02:45:02 -0000 Hey! Thanks for the lightning fast follow up. I have a driver from OpenSolaris, but I haven't tried to compile it on FreeBSD (if it even will with a bit of tweaking is uncertain). I have about 20 of these things (factory new actually, no idea where they've been hiding or how long...). I'll probably use a PCI-to-SD card for ZIL in this project, but if I get the driver from OpenSolaris to work, I'll put it up somewhere for others to mess with. Probably not worth writing a driver from scratch considering the vintage. And my apologies on the NAND/ECC mixup. That should have been obvious to me looking at the Hynix chips on the thing... Not sure what you mean about the slot though. These were manufactured in July of '03, and the datasheet in the packaging specifies PCI-X 64-bit/66MHz Rev 1.0a, but it is indeed an MMI product. Thanks for pointing me at the PowerPC port, that should be helpful in a few other areas I'm tinkering... Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder Matthew Jacob wrote: > On 4/20/2010 8:05 PM, Erich Jenkins, Fuujin Group Ltd wrote: >> Posted this to the SCSI list about a week ago, but with no responses, >> I suspect it should have been posted here. Sorry for cross-posting: > > (Hi, Erich!) > >> >> Not sure if the NAND drivers being written at >> http://wiki.freebsd.org/NAND apply to this device or not. It appears >> this is more of a simulator at the moment and an experimental >> framework. Is there any current support for the MM-5425CN series NAND >> flash cards in FreeBSD? These seem like they'd be excellent for a >> separate ZIL in a ZFS raidz config if installed in pairs for mirroring... >> >> Here's the pciconf probe of the device in question: >> >> none3@pci0:6:2:0: class=0x058000 card=0x00000000 chip=0x54251332 >> rev=0x06 hdr=0x00 >> vendor = 'Micro Memory' >> device = 'MM-5425CN PCI 64/66 Memory Module with Battery Backup' >> class = memory >> >> >> > > This looks like the old MMI card- not NAND. It's ECC ram with a battery. > It won't fit into PCI-X slots- it predates it. > > It has a linux driver for it. DataDomain used it in there 200 series > model. NetApp used it a while back too. It has a history going back to > SBus PrestoServe. > > I don't believe anyone has ever done a FreeBSD driver. MMI got eaten up > by Curtiss Wright a year or so ago. I actually have one, but considering > that the connectivity to such a card, no matter how nice, isn't worth > it. I don't believe they're being built any more. > > Insofar as NAND drivers, you might check with the PowerPC FreeBSD port > people- they've just done a bunch of changes and look like they're > supporting some of the embedded stuff, which means they'll have that > entire wad of NAND and NOR based device support at their fingers. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 02:48:06 2010 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 3ADDB1065670 for ; Wed, 21 Apr 2010 02:48:06 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id B9D518FC15 for ; Wed, 21 Apr 2010 02:48:05 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas06p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100421024803.CMQR18201.nschwmtas06p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Wed, 21 Apr 2010 02:48:03 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100421024803.UDTM2131.nschwotgx02p.mx.bigpond.com@duncan.reilly.home>; Wed, 21 Apr 2010 02:48:03 +0000 Date: Wed, 21 Apr 2010 12:48:03 +1000 From: Andrew Reilly To: David N Message-ID: <20100421024803.GA25701@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Wed, 21 Apr 2010 02:48:03 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4BCE6763.0102,ss=1,fgs=0 X-SIH-MSG-ID: oxs6FNz4TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRsM6kxDxNJhqHNGUoaaznTY3Rs9mK Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 02:48:06 -0000 Hi David, On Wed, Apr 21, 2010 at 12:20:46PM +1000, David N wrote: > Gjournal on my systems are pretty quick on startup after a power outtage. Great to hear! > What kind of disks are you using? Or what hardware are you using? Several: main /usr is on a gjournal on top of a gmirror over a pair of Samsung 1TB 3.5" SATA drives, but I have other gjournals on a 750G WD SATA, a 1.5T Seagate and another 1TB WD MyBook firewire unit. There is brokenness in the firewire connection that results in me always coming up manually through single-user mode, at the moment. In single user mode pilot error is sufficient to account for the problems that I was having with mount vs fsck of the gjournalled drives, I'm fairly sure. The firewire issue is strange: at boot-up the fw stack (this is 9-current) doesn't reset the bus well enough or for long enough for the drive to be fully recognised and show up in /dev, but a post-boot "fwcontrol -r" does the job nicely. It's a bit inconvenient that fwcontrol is in /usr/sbin, rather than /sbin, so it's not available until the rest of the mounts are complete. USB "works" but is sufficiently slower that I'm prepared to hand-hold the boot process in order to have my backups finish in reasonable time. > Might be the disks are ignoring the BIO_FLUSH. Not sure: how could I tell? Thanks for the support and suggestions. Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 05:49:54 2010 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 996541065678 for ; Wed, 21 Apr 2010 05:49:54 +0000 (UTC) (envelope-from julianelischer@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 4EC928FC1C for ; Wed, 21 Apr 2010 05:49:54 +0000 (UTC) Received: by gyh20 with SMTP id 20so3682155gyh.13 for ; Tue, 20 Apr 2010 22:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QkaaHpkzzRgwsAYLiHC5/IBCrsn1LkmTGDeUUbSu08M=; b=wLsgbxUFYLRPpdbEiKyOR1QMPUj8b2rGxGH/Kz4iQQBMHt3ojdC/xlg4QPtGm2Tq3z 5V50fW/Ds4ArnRbLQySwZlcc2qYF0inIwXn7kWDFtUePkMfHL4qxYm7PkRzgQnZXwFbk Vk+zJ/R6GReAiQpXlGqSTC+BnnanzO2m+vVIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rQ6aE1si2ikAa9a4lsCJDjSGtqI4LkviQeateABYEWGei3AZNZ/l5eTZcRiHgWnZil KqpewS1BfN/q/Q0u0nYrGsJt2NWC1GdQjG0YIZWgGy80eunn7hjqE9pwoM3YUBz8ckRV HO1gA/Kzq5FdhzbNrMilcLGajx1+4mebf1BZA= Received: by 10.101.6.37 with SMTP id j37mr19181858ani.182.1271827358131; Tue, 20 Apr 2010 22:22:38 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 16sm5247343gxk.13.2010.04.20.22.22.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 22:22:36 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BCE8B9A.4050904@elischer.org> Date: Tue, 20 Apr 2010 22:22:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Erich Jenkins, Fuujin Group Ltd" References: <4BCE6B95.3010409@fuujingroup.com> In-Reply-To: <4BCE6B95.3010409@fuujingroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: MM-5425CN nand SSD 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, 21 Apr 2010 05:49:54 -0000 On 4/20/10 8:05 PM, Erich Jenkins, Fuujin Group Ltd wrote: > Posted this to the SCSI list about a week ago, but with no responses, I > suspect it should have been posted here. Sorry for cross-posting: > > Not sure if the NAND drivers being written at > http://wiki.freebsd.org/NAND apply to this device or not. It appears > this is more of a simulator at the moment and an experimental framework. > Is there any current support for the MM-5425CN series NAND flash cards > in FreeBSD? These seem like they'd be excellent for a separate ZIL in a > ZFS raidz config if installed in pairs for mirroring... MM-5425CN is battery backed up SDRAM according to google so I'm no sure what teh relationship with NAND is.. > > Here's the pciconf probe of the device in question: > > none3@pci0:6:2:0: class=0x058000 card=0x00000000 chip=0x54251332 > rev=0x06 hdr=0x00 > vendor = 'Micro Memory' > device = 'MM-5425CN PCI 64/66 Memory Module with Battery Backup' > class = memory > > > From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 08:05:03 2010 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 701951065670 for ; Wed, 21 Apr 2010 08:05:03 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 21EF88FC08 for ; Wed, 21 Apr 2010 08:05:02 +0000 (UTC) Received: by qyk11 with SMTP id 11so7810431qyk.13 for ; Wed, 21 Apr 2010 01:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=81z+bp8ZEj9mWszAysV7zT9s9n5E1CoJ/TrBN3EsTlQ=; b=cKgFV5PrcLtucG8TIeReIz3AU9w8/KHVa5Um6Y+RLZVcISq/PHmY4RnTYUfO06CKua 4/xGhkiKTvMzseuJ5D8Se2y1liSKXxvWvwkSfKDMsRaalXPh5u8cJf0pa2piKioUsERu W6FTco79yBpPiXOpkuY5z+rHFRNA8I7+W6qDw= 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=NQV3QNKSmABZiOQR60L4adPXDGJu45+sjSZ5COuZmWPJf2RWLwUwt4opIiLOWuC2JK VnpIJT8ispZs6Dg5IY6nIp07BnuAAlS3DSIm8bqEienARDweNPBgRkoi1WQsYrX39eQJ h2Fab76DpITMBwnDt/MTpiBL5yOUNPt8HjaUs= MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Wed, 21 Apr 2010 01:05:02 -0700 (PDT) In-Reply-To: <20100421024803.GA25701@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> Date: Wed, 21 Apr 2010 18:05:02 +1000 Received: by 10.229.227.5 with SMTP id iy5mr5224063qcb.29.1271837102301; Wed, 21 Apr 2010 01:05:02 -0700 (PDT) Message-ID: From: David N To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 08:05:03 -0000 On 21 April 2010 12:48, Andrew Reilly wrote: > Hi David, > > On Wed, Apr 21, 2010 at 12:20:46PM +1000, David N wrote: >> Gjournal on my systems are pretty quick on startup after a power outtage= . > > Great to hear! > >> What kind of disks are you using? Or what hardware are you using? > > Several: main /usr is on a gjournal on top of a gmirror over a > pair of Samsung 1TB 3.5" SATA drives, but I have other gjournals > on a 750G WD SATA, a 1.5T Seagate and another 1TB WD MyBook > firewire unit. =A0There is brokenness in the firewire connection > that results in me always coming up manually through single-user > mode, at the moment. =A0In single user mode pilot error is > sufficient to account for the problems that I was having with > mount vs fsck of the gjournalled drives, I'm fairly sure. > > The firewire issue is strange: at boot-up the fw stack (this > is 9-current) doesn't reset the bus well enough or for long > enough for the drive to be fully recognised and show up in /dev, > but a post-boot "fwcontrol -r" does the job nicely. =A0It's a bit > inconvenient that fwcontrol is in /usr/sbin, rather than /sbin, > so it's not available until the rest of the mounts are complete. > USB "works" but is sufficiently slower that I'm prepared to > hand-hold the boot process in order to have my backups finish in > reasonable time. > >> Might be the disks are ignoring the BIO_FLUSH. > > Not sure: how could I tell? > > Thanks for the support and suggestions. > > Cheers, > > -- > Andrew > Wow, thats a setup. I have a few more questions. Your first email, you mentioned gjournal overflow panics. Have you fixed th= at? I see you are gmirroring the slices, when you did the gmirror + gjournal slice, did you check the bsdlabel? sometimes it doesn't report the right block size, and the disk + journal overlap. I had this happen to me on my first setup which resulted in the overflow panics. Its not as easy as a gmirror label ... gjournal label ... You gotta check the bsdlabel each time to make sure the c slice and additional slices are the correct size. If you do decide to do it again, gpt made it really easy. Did you use newfs -J to format the slices/journal? Regards David N From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 08:52:32 2010 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 00A9E1065675 for ; Wed, 21 Apr 2010 08:52:32 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3A48FC1D for ; Wed, 21 Apr 2010 08:52:31 +0000 (UTC) Received: from nschwotgx02p.mx.bigpond.com ([124.188.161.100]) by nschwmtas05p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100421085229.CIRM6690.nschwmtas05p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Wed, 21 Apr 2010 08:52:29 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20100421085229.PZTA2131.nschwotgx02p.mx.bigpond.com@duncan.reilly.home>; Wed, 21 Apr 2010 08:52:29 +0000 Date: Wed, 21 Apr 2010 18:52:28 +1000 From: Andrew Reilly To: David N Message-ID: <20100421085228.GA27892@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Wed, 21 Apr 2010 08:52:28 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4BCEBCCD.00C7,ss=1,fgs=0 X-SIH-MSG-ID: rhozE9P/TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRsM6kxDxNJhqNNGQiaa7tTY3Rs9mK Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 08:52:32 -0000 On Wed, Apr 21, 2010 at 06:05:02PM +1000, David N wrote: > On 21 April 2010 12:48, Andrew Reilly wrote: > > On Wed, Apr 21, 2010 at 12:20:46PM +1000, David N wrote: > >> What kind of disks are you using? Or what hardware are you using? > > > > Several: main /usr is on a gjournal on top of a gmirror over a > > pair of Samsung 1TB 3.5" SATA drives, but I have other gjournals > > on a 750G WD SATA, a 1.5T Seagate and another 1TB WD MyBook > > firewire unit.  There is brokenness in the firewire connection > > that results in me always coming up manually through single-user > > mode, at the moment.  In single user mode pilot error is > > sufficient to account for the problems that I was having with > > mount vs fsck of the gjournalled drives, I'm fairly sure. > Wow, thats a setup. More an artifact of fair old age and accretion than design... > I have a few more questions. > > Your first email, you mentioned gjournal overflow panics. Have you fixed that? No: I've avoided it, at risk of incomplete backups, by leaving the -L (snapshot) option off my backup "dump" calls. I'm fairly certain that I can generate those panics on demand, now that I know what's causing them. (I prefer not to, of course, this machine is in constant use.) > I see you are gmirroring the slices, when you did the gmirror + > gjournal slice, did you check the bsdlabel? sometimes it doesn't > report the right block size, and the disk + journal overlap. I had > this happen to me on my first setup which resulted in the overflow > panics. Not sure about that. All of my disks only have one bsdlabel, on the raw provider. I fdisk -BI; bsdlabel -w -B and then newfs the ...s1a partition, as a general rule. Now that I'm running gjournal, that's fdisk; bsdlabel; gjournal label ...; newfs ...s1a.journal. There isn't a label between the gjournal and the file system. In the case of my main, gmirrored disk pair, I bsdlabel -e'd after the "use whole disk" standard procedure and made liberal use of "*" wildcards to make sure that bsdlabel did the right thing. I was *very* glad when I didn't have to muck about calculating sector offsets any more. I have my mirror'd pair layered: fdisk; bsdlabel; gmirror on ad[46]s1a, ad[46]s1d and ad[46]s1e, separately, rather than mirroring the raw ad4/ad6 pair and then bsdlabeling the resulting mirror because I couldn't see the point in swapping to a mirror. So I swap to ad4s1b and ad6s1b independently. So I have root on mirror/gm0a (no soft-updates), var on mirror/gm0d (with soft-updates), and a gjournal on mirror/gm0e, with a newfs -J partition on mirror/gm0e.journal > Its not as easy as a > gmirror label ... > gjournal label ... > You gotta check the bsdlabel each time to make sure the c slice and > additional slices are the correct size. I didn't think that GEOM layers needed to have a bsdlabel each, and newfs is happy enough (I think) to sit on an unlabelled GEOM provider. Certainly the examples in the gjournal, gmirror and mdconfig man pages seem to suggest that newfs'ing straight onto one of them is the way to go. > If you do decide to do it again, gpt made it really easy. What's a gpt? Neither man nor bash know about it on my system. > Did you use newfs -J to format the slices/journal? Yup. Thanks for the help and suggestions! Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 09:02:24 2010 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 2CD65106567B for ; Wed, 21 Apr 2010 09:02:24 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 88A668FC1B for ; Wed, 21 Apr 2010 09:02:20 +0000 (UTC) Received: by bwz28 with SMTP id 28so7919582bwz.14 for ; Wed, 21 Apr 2010 02:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:organization :date:message-id:user-agent:mime-version:content-type; bh=tNiEOH3/XfJouf7c5MullsBFm7F00jXJbHGC2GD//r0=; b=tjIXT0bvntChxbbAe84dYq2KMISjEyBTHusiIPTQ3W1ZqMg2MAqJaeaJlR1ZULm0zb W53uMPNS46OO8I/N7/8VYd1CqAT0NHi1NDdVr9cP5Zy6WGwUxQ6v2rVeKt1IQz2iZ7Su rMolOLrCLrI2mMs5tY6bQObBRYhxFtl9YWL/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:organization:date:message-id:user-agent :mime-version:content-type; b=XbSTiWAmqULptz8bKPwo2SvWYu5m3i/j0TIGvh7NGJOq9WiW5IZNjPVTu2GzC3TZJq 89Qpgoz5+//4RYGadFP24TcsrghQlvbTfEoeKl7Cjqc6EGmHJJ5wprTgumDwrsFutlDa 7MDj4mi4fQ5i3gadO2QduXCGmBlmuCrsG/QLc= Received: by 10.204.22.75 with SMTP id m11mr6799039bkb.51.1271840539733; Wed, 21 Apr 2010 02:02:19 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 15sm4003006bwz.0.2010.04.21.02.02.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 02:02:18 -0700 (PDT) From: Mikolaj Golub To: freebsd-fs Organization: TOA Ukraine Date: Wed, 21 Apr 2010 12:02:16 +0300 Message-ID: <86r5m9dvqf.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: HAST: primary might get stuck when there are connectivity problems with secondary 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, 21 Apr 2010 09:02:24 -0000 --=-=-= Hi, I can make HAST primary get stuck making the secondary not accessible (network packets are lost) for some period of time. I run HAST in VirtualBox hosts, so to emulate network outage I just change bridge interface in VirtualBox configuration. Below are details for one example. On the primary before the outage we have: sockstat: root hastd 1571 10 tcp4 172.20.66.201:41841 172.20.66.202:8457 root hastd 1571 11 tcp4 172.20.66.201:57596 172.20.66.202:8457 During the outage and after it sockstat shows the same, while netstat shows: tcp4 0 0 172.20.66.201.57596 172.20.66.202.8457 ESTABLISHED tcp4 0 8307 172.20.66.201.41841 172.20.66.202.8457 ESTABLISHED (note non zero value for send buffer) and then later tcp4 0 0 172.20.66.201.57596 172.20.66.202.8457 ESTABLISHED tcp4 0 0 172.20.66.201.41841 172.20.66.202.8457 CLOSED Restoring network after this changes nothing. Primary gets stuck. No messages in the log and "dirty" in status output does not change: [root@hasta ~]# hastctl status storage: role: primary provname: storage localpath: /dev/ad4 extentsize: 2097152 keepdirty: 64 remoteaddr: 172.20.66.202 replication: memsync status: complete dirty: 2097152 bytes On the secondary we have all this time: tcp4 0 0 172.20.66.202.8457 172.20.66.201.57596 ESTABLISHED tcp4 0 0 172.20.66.202.8457 172.20.66.201.41841 ESTABLISHED The last messages in log: Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0) Request received from the kernel: READ(13565952, 65536). Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0) Moving request to the send queue. Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: Taking free request. Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80) Got free request. Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80) Waiting for request from the kernel. Apr 21 10:50:21 hasta hastd: [storage] (primary) local_send: (0x28411bc0) Got request. Apr 21 10:50:21 hasta hastd: [storage] (primary) local_send: (0x28411bc0) Moving request to the done queue. Apr 21 10:50:21 hasta hastd: [storage] (primary) local_send: Taking request. Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_send: (0x28411bc0) Got request. Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_send: (0x28411bc0) Moving request to the free queue. Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_send: Taking request. Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80) Request received from the kernel: READ(1812529152, 65536). Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80) Moving request to the send queue. Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: Taking free request. Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b00) Got free request. Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b00) Waiting for request from the kernel. Apr 21 10:51:00 hasta hastd: [storage] (primary) local_send: (0x28411b80) Got request. Apr 21 10:51:00 hasta hastd: [storage] (primary) local_send: (0x28411b80) Moving request to the done queue. Apr 21 10:51:00 hasta hastd: [storage] (primary) local_send: Taking request. Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_send: (0x28411b80) Got request. Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_send: (0x28411b80) Moving request to the free queue. Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_send: Taking request. The backtrace of gotten stuck hastd is in the attach. I interpret this in the following way. Although the network is down hast_proto_send() in remote_send_thread() returns success (sent data are stored in the kernel buffer). Then kernel tries to send data and eventually fails after timeout and close the socket. hastd is not aware about this, remote_send_thread() is blocked in "Taking request" at this time, sync thread is waiting for status from the secondary about sent data but secondary does not send it because it did not receive any data. Restarting hastd on the secondary usually helps. A workaround is to set net.inet.tcp.keepidle to some small value (e.g. 300 sec) on the secondary. Then the secondary will notice much earlier that the peer has closed the connection and will restart the worker itself: Apr 21 11:52:21 hastb hastd: [storage] (secondary) Unable to receive request header: Connection reset by peer. Apr 21 11:52:21 hastb hastd: [storage] (secondary) Worker process (pid=1398) exited ungracefully: status=19200. -- Mikolaj Golub --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=bt.log Content-Transfer-Encoding: base64 VGhyZWFkIDggKFRocmVhZCAyODQwNDE0MCAoTFdQIDEwMDA3OCkpOgojMCAgMHgyODIzZWRkNyBp biBfX2Vycm9yICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwojMSAgMHgyODIzZTliOCBpbiBfX2Vy cm9yICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwojMiAgMHgyODRjMzUyMCBpbiA/PyAoKQojMyAg MHgwMDAwMDAwOCBpbiA/PyAoKQojNCAgMHgwMDAwMDAwMSBpbiA/PyAoKQojNSAgMHgyODRjMzUw MCBpbiA/PyAoKQojNiAgMHgwMDAwMDAwMCBpbiA/PyAoKQojNyAgMHgyODBhNWEwMCBpbiA/PyAo KQojOCAgMHhiZmJmZTk4MCBpbiA/PyAoKQojOSAgMHgyODIzZDMxZiBpbiBwdGhyZWFkX3NldGNh bmNlbHN0YXRlICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwojMTAgMHgyODIzY2JiZSBpbiBwdGhy ZWFkX2NvbmRfc2lnbmFsICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwojMTEgMHgwODA1OGU3OCBp biBjdl93YWl0IChjdj0weDgwNjdlMmMsIGxvY2s9MHg4MDY3ZTI4KSBhdCBzeW5jaC5oOjEyNQoj MTIgMHgwODA1Yjc1ZSBpbiBjdl90aW1lZHdhaXQgKGN2PTB4ODA2N2UyYywgbG9jaz0weDgwNjdl MjgsIHRpbWVvdXQ9MCkgYXQgc3luY2guaDoxMzUKIzEzIDB4MDgwNWI3MmMgaW4gZ3VhcmRfdGhy ZWFkIChhcmc9MHgyODRjYWIwMCkgYXQgL3Vzci9zcmMvc2Jpbi9oYXN0ZC9wcmltYXJ5LmM6MTc4 NwojMTQgMHgwODA1ODIwNiBpbiBoYXN0ZF9wcmltYXJ5IChyZXM9MHgyODRjYWIwMCkgYXQgL3Vz ci9zcmMvc2Jpbi9oYXN0ZC9wcmltYXJ5LmM6NzczCiMxNSAweDA4MDRjNGU4IGluIGNvbnRyb2xf c2V0X3JvbGUgKGNmZz0weDgwNjY1MDAsIG52b3V0PTB4Mjg0ZWIwYjAsIHJvbGU9MiAnXDAwMics IHJlcz0weDI4NGNhYjAwLCAKICAgIG5hbWU9MHgyODQ4MTQ0MiAic3RvcmFnZSIsIG5vPTApIGF0 IC91c3Ivc3JjL3NiaW4vaGFzdGQvY29udHJvbC5jOjExNAojMTYgMHgwODA0Y2QwMSBpbiBjb250 cm9sX2hhbmRsZSAoY2ZnPTB4ODA2NjUwMCkgYXQgL3Vzci9zcmMvc2Jpbi9oYXN0ZC9jb250cm9s LmM6MzMyCiMxNyAweDA4MDRmMDdjIGluIG1haW5fbG9vcCAoKSBhdCAvdXNyL3NyYy9zYmluL2hh c3RkL2hhc3RkLmM6NDI1CiMxOCAweDA4MDRmM2U4IGluIG1haW4gKGFyZ2M9MCwgYXJndj0weGJm YmZlZGE0KSBhdCAvdXNyL3NyYy9zYmluL2hhc3RkL2hhc3RkLmM6NTIxCgpUaHJlYWQgNyAoVGhy ZWFkIDI4NDA0MjgwIChMV1AgMTAwMTExKSk6CiMwICAweDI4MzQ0NzczIGluIGlvY3RsICgpIGZy b20gL2xpYi9saWJjLnNvLjcKIzEgIDB4MDgwNTg4YzQgaW4gZ2dhdGVfcmVjdl90aHJlYWQgKGFy Zz0weDI4NGNhYjAwKSBhdCAvdXNyL3NyYy9zYmluL2hhc3RkL3ByaW1hcnkuYzo4OTQKIzIgIDB4 MjgyMzQyOGYgaW4gcHRocmVhZF9nZXRwcmlvICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwojMyAg MHgwMDAwMDAwMCBpbiA/PyAoKQoKVGhyZWFkIDYgKFRocmVhZCAyODQwNDNjMCAoTFdQIDEwMDEx MikpOgojMCAgMHgyODIzZWRkNyBpbiBfX2Vycm9yICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwoj MSAgMHgyODIzZTliOCBpbiBfX2Vycm9yICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwojMiAgMHgy ODRjMzJhMCBpbiA/PyAoKQojMyAgMHgwMDAwMDAwOCBpbiA/PyAoKQojNCAgMHgwMDAwMDAwMSBp biA/PyAoKQojNSAgMHgyODRjMzI4MCBpbiA/PyAoKQojNiAgMHgwMDAwMDAwMCBpbiA/PyAoKQoj NyAgMHhiZjhmZGU5NCBpbiA/PyAoKQojOCAgMHgyODIzOGRiNSBpbiBwdGhyZWFkX3J3bG9ja191 bmxvY2sgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiM5ICAweDI4MjNjYmJlIGluIHB0aHJlYWRf Y29uZF9zaWduYWwgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxMCAweDA4MDU4ZTc4IGluIGN2 X3dhaXQgKGN2PTB4Mjg0YzkwODAsIGxvY2s9MHgyODRjOTA3OCkgYXQgc3luY2guaDoxMjUKIzEx IDB4MDgwNThmMzcgaW4gbG9jYWxfc2VuZF90aHJlYWQgKGFyZz0weDI4NGNhYjAwKSBhdCAvdXNy L3NyYy9zYmluL2hhc3RkL3ByaW1hcnkuYzoxMDMyCiMxMiAweDI4MjM0MjhmIGluIHB0aHJlYWRf Z2V0cHJpbyAoKSBmcm9tIC9saWIvbGlidGhyLnNvLjMKIzEzIDB4MDAwMDAwMDAgaW4gPz8gKCkK ClRocmVhZCA1IChUaHJlYWQgMjg0MDQ1MDAgKExXUCAxMDAxMTMpKToKIzAgIDB4MjgyM2VkZDcg aW4gX19lcnJvciAoKSBmcm9tIC9saWIvbGlidGhyLnNvLjMKIzEgIDB4MjgyM2U5YjggaW4gX19l cnJvciAoKSBmcm9tIC9saWIvbGlidGhyLnNvLjMKIzIgIDB4Mjg0YzMzYTAgaW4gPz8gKCkKIzMg IDB4MDAwMDAwMDggaW4gPz8gKCkKIzQgIDB4MDAwMDAwMDEgaW4gPz8gKCkKIzUgIDB4Mjg0YzMz ODAgaW4gPz8gKCkKIzYgIDB4MDAwMDAwMDAgaW4gPz8gKCkKIzcgIDB4MDAwMDAwMDAgaW4gPz8g KCkKIzggIDB4ZDJlZGUzODkgaW4gPz8gKCkKIzkgIDB4MjgyM2QzMWYgaW4gcHRocmVhZF9zZXRj YW5jZWxzdGF0ZSAoKSBmcm9tIC9saWIvbGlidGhyLnNvLjMKIzEwIDB4MjgyM2NiYmUgaW4gcHRo cmVhZF9jb25kX3NpZ25hbCAoKSBmcm9tIC9saWIvbGlidGhyLnNvLjMKIzExIDB4MDgwNThlNzgg aW4gY3Zfd2FpdCAoY3Y9MHgyODRjOTA4NCwgbG9jaz0weDI4NGM5MDdjKSBhdCBzeW5jaC5oOjEy NQojMTIgMHgwODA1OTUwZiBpbiByZW1vdGVfc2VuZF90aHJlYWQgKGFyZz0weDI4NGNhYjAwKSBh dCAvdXNyL3NyYy9zYmluL2hhc3RkL3ByaW1hcnkuYzoxMTE3CiMxMyAweDI4MjM0MjhmIGluIHB0 aHJlYWRfZ2V0cHJpbyAoKSBmcm9tIC9saWIvbGlidGhyLnNvLjMKIzE0IDB4MDAwMDAwMDAgaW4g Pz8gKCkKClRocmVhZCA0IChUaHJlYWQgMjg0MDQ2NDAgKExXUCAxMDAxMTQpKToKIzAgIDB4Mjgy ZmFhNTcgaW4gcmVjdmZyb20gKCkgZnJvbSAvbGliL2xpYmMuc28uNwojMSAgMHgyODI4MGJlMiBp biByZWN2ICgpIGZyb20gL2xpYi9saWJjLnNvLjcKIzIgIDB4MDgwNWMyODcgaW4gcHJvdG9fY29t bW9uX3JlY3YgKGZkPTExLCBkYXRhPTB4YmY2ZmJmMjcgIiIsIHNpemU9NSkKICAgIGF0IC91c3Iv c3JjL3NiaW4vaGFzdGQvcHJvdG9fY29tbW9uLmM6NzgKIzMgIDB4MDgwNWQ0ZjAgaW4gdGNwNF9y ZWN2IChjdHg9MHgyODQ3ZjIyMCwgZGF0YT0weGJmNmZiZjI3ICIiLCBzaXplPTUpCiAgICBhdCAv dXNyL3NyYy9zYmluL2hhc3RkL3Byb3RvX3RjcDQuYzozMjUKIzQgIDB4MDgwNWJkZjEgaW4gcHJv dG9fcmVjdiAoY29ubj0weDI4NGViMTUwLCBkYXRhPTB4YmY2ZmJmMjcsIHNpemU9NSkgYXQgL3Vz ci9zcmMvc2Jpbi9oYXN0ZC9wcm90by5jOjE5OAojNSAgMHgwODA0ZGRhZSBpbiBoYXN0X3Byb3Rv X3JlY3ZfaGRyIChjb25uPTB4Mjg0ZWIxNTAsIG52cD0weGJmNmZiZjdjKSBhdCAvdXNyL3NyYy9z YmluL2hhc3RkL2hhc3RfcHJvdG8uYzoyOTgKIzYgIDB4MDgwNTllZjkgaW4gcmVtb3RlX3JlY3Zf dGhyZWFkIChhcmc9MHgyODRjYWIwMCkgYXQgL3Vzci9zcmMvc2Jpbi9oYXN0ZC9wcmltYXJ5LmM6 MTI4MgojNyAgMHgyODIzNDI4ZiBpbiBwdGhyZWFkX2dldHByaW8gKCkgZnJvbSAvbGliL2xpYnRo ci5zby4zCiM4ICAweDAwMDAwMDAwIGluID8/ICgpCgpUaHJlYWQgMyAoVGhyZWFkIDI4NDA0Nzgw IChMV1AgMTAwMTE1KSk6CiMwICAweDI4MjNlZGQ3IGluIF9fZXJyb3IgKCkgZnJvbSAvbGliL2xp YnRoci5zby4zCiMxICAweDI4MjNlOWI4IGluIF9fZXJyb3IgKCkgZnJvbSAvbGliL2xpYnRoci5z by4zCiMyICAweDI4NGMzNGEwIGluID8/ICgpCiMzICAweDAwMDAwMDA4IGluID8/ICgpCiM0ICAw eDAwMDAwMDAxIGluID8/ICgpCiM0ICAweDAwMDAwMDAxIGluID8/ICgpCiM1ICAweDI4NGMzNDgw IGluID8/ICgpCiM2ICAweDAwMDAwMDAwIGluID8/ICgpCiM3ICAweDAwMDAwMDAwIGluID8/ICgp CiM4ICAweDAwMDAwMDAwIGluID8/ICgpCiM5ICAweDI4MjNkMzFmIGluIHB0aHJlYWRfc2V0Y2Fu Y2Vsc3RhdGUgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxMCAweDI4MjNjYmJlIGluIHB0aHJl YWRfY29uZF9zaWduYWwgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxMSAweDA4MDU4ZTc4IGlu IGN2X3dhaXQgKGN2PTB4ODA2N2UxNCwgbG9jaz0weDgwNjdlMTApIGF0IHN5bmNoLmg6MTI1CiMx MiAweDA4MDVhNDBiIGluIGdnYXRlX3NlbmRfdGhyZWFkIChhcmc9MHgyODRjYWIwMCkgYXQgL3Vz ci9zcmMvc2Jpbi9oYXN0ZC9wcmltYXJ5LmM6MTM4MwojMTMgMHgyODIzNDI4ZiBpbiBwdGhyZWFk X2dldHByaW8gKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxNCAweDAwMDAwMDAwIGluID8/ICgp CgpUaHJlYWQgMiAoVGhyZWFkIDI4NDA0OGMwIChMV1AgMTAwMTE2KSk6CiMwICAweDI4MjNlZGQ3 IGluIF9fZXJyb3IgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxICAweDI4MjNlOWI4IGluIF9f ZXJyb3IgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMyICAweDI4NGMzMWEwIGluID8/ICgpCiMz ICAweDAwMDAwMDA4IGluID8/ICgpCiM0ICAweDAwMDAwMDAxIGluID8/ICgpCiM1ICAweDI4NGMz MTgwIGluID8/ICgpCiM2ICAweDAwMDAwMDAwIGluID8/ICgpCiM3ICAweDAwMDAwMDAwIGluID8/ ICgpCiM4ICAweGJmNGY5ZWE4IGluID8/ICgpCiM5ICAweDI4MjNkMzFmIGluIHB0aHJlYWRfc2V0 Y2FuY2Vsc3RhdGUgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxMCAweDI4MjNjYmJlIGluIHB0 aHJlYWRfY29uZF9zaWduYWwgKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxMSAweDA4MDU4ZTc4 IGluIGN2X3dhaXQgKGN2PTB4ODA2N2UyMCwgbG9jaz0weDgwNjdlMWMpIGF0IHN5bmNoLmg6MTI1 CiMxMiAweDA4MDVhN2NjIGluIHN5bmNfdGhyZWFkIChhcmc9MHgyODRjYWIwMCkgYXQgL3Vzci9z cmMvc2Jpbi9oYXN0ZC9wcmltYXJ5LmM6MTQ3MgojMTMgMHgyODIzNDI4ZiBpbiBwdGhyZWFkX2dl dHByaW8gKCkgZnJvbSAvbGliL2xpYnRoci5zby4zCiMxNCAweDAwMDAwMDAwIGluID8/ICgpCgpU aHJlYWQgMSAoVGhyZWFkIDI4NDA0YTAwIChMV1AgMTAwMTE3KSk6CiMwICAweDI4MmZhYTU1IGlu IHJlY3Zmcm9tICgpIGZyb20gL2xpYi9saWJjLnNvLjcKIzEgIDB4MjgyODBiZTIgaW4gcmVjdiAo KSBmcm9tIC9saWIvbGliYy5zby43CiMyICAweDA4MDVjMjg3IGluIHByb3RvX2NvbW1vbl9yZWN2 IChmZD05LCBkYXRhPTB4YmYzZjhmNDcgIioiLCBzaXplPTUpCiAgICBhdCAvdXNyL3NyYy9zYmlu L2hhc3RkL3Byb3RvX2NvbW1vbi5jOjc4CiMzICAweDA4MDVjNmFlIGluIHNwX3JlY3YgKGN0eD0w eDI4NGViMTAwLCBkYXRhPTB4YmYzZjhmNDcgIioiLCBzaXplPTUpCiAgICBhdCAvdXNyL3NyYy9z YmluL2hhc3RkL3Byb3RvX3NvY2tldHBhaXIuYzoxNzcKIzQgIDB4MDgwNWJkZjEgaW4gcHJvdG9f cmVjdiAoY29ubj0weDI4NGViMGYwLCBkYXRhPTB4YmYzZjhmNDcsIHNpemU9NSkgYXQgL3Vzci9z cmMvc2Jpbi9oYXN0ZC9wcm90by5jOjE5OAojNSAgMHgwODA0ZGRhZSBpbiBoYXN0X3Byb3RvX3Jl Y3ZfaGRyIChjb25uPTB4Mjg0ZWIwZjAsIG52cD0weGJmM2Y4ZjgwKSBhdCAvdXNyL3NyYy9zYmlu L2hhc3RkL2hhc3RfcHJvdG8uYzoyOTgKIzYgIDB4MDgwNGNlMjcgaW4gY3RybF90aHJlYWQgKGFy Zz0weDI4NGNhYjAwKSBhdCAvdXNyL3NyYy9zYmluL2hhc3RkL2NvbnRyb2wuYzozNzMKIzcgIDB4 MjgyMzQyOGYgaW4gcHRocmVhZF9nZXRwcmlvICgpIGZyb20gL2xpYi9saWJ0aHIuc28uMwojOCAg MHgwMDAwMDAwMCBpbiA/PyAoKQo= --=-=-=-- From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 09:16:09 2010 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 883811065672 for ; Wed, 21 Apr 2010 09:16:09 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 3CB328FC1C for ; Wed, 21 Apr 2010 09:16:08 +0000 (UTC) Received: by qyk11 with SMTP id 11so7871327qyk.13 for ; Wed, 21 Apr 2010 02:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jddnwu0k5Z+zao1F1IQulho3Xv7r5kxjwGnZVso47Nw=; b=KFIJnKeiCNcA8DjLwb/Uk+5Ey+OOPHTd5KWOB4vHq3SCUHKgI4YM3OJ+mV5UZponyH TTMYNChhnKfsXVP3q4ZE0X33Tgz8mzZgiiNLXILygElYdDIMkZOHQlslkh4nZ3fpYzQZ 2+wsKHdW/Psdv/WNC57JTYRMHug7M6FnWYJqI= 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=vdqJeAhvODlLUw6Hs2BWq4fBywjeGZF8Wwj7ExtObqYzlZVqFfpCCFu7RzmeZufO2g kzBH2o04C7KtlnhgBq6EiLQCjmWUDzYRAdPQeDn1giDSDAw4jNK38zfSuixrSs+njvmU 1DFKwditqOkO04eJOf0FIh67dLP19XT5Z3TTQ= MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Wed, 21 Apr 2010 02:16:08 -0700 (PDT) In-Reply-To: <20100421085228.GA27892@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> Date: Wed, 21 Apr 2010 19:16:08 +1000 Received: by 10.229.221.78 with SMTP id ib14mr1743530qcb.28.1271841368152; Wed, 21 Apr 2010 02:16:08 -0700 (PDT) Message-ID: From: David N To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 09:16:09 -0000 On 21 April 2010 18:52, Andrew Reilly wrote: > On Wed, Apr 21, 2010 at 06:05:02PM +1000, David N wrote: >> On 21 April 2010 12:48, Andrew Reilly wrote: >> > On Wed, Apr 21, 2010 at 12:20:46PM +1000, David N wrote: >> >> What kind of disks are you using? Or what hardware are you using? >> > >> > Several: main /usr is on a gjournal on top of a gmirror over a >> > pair of Samsung 1TB 3.5" SATA drives, but I have other gjournals >> > on a 750G WD SATA, a 1.5T Seagate and another 1TB WD MyBook >> > firewire unit. =A0There is brokenness in the firewire connection >> > that results in me always coming up manually through single-user >> > mode, at the moment. =A0In single user mode pilot error is >> > sufficient to account for the problems that I was having with >> > mount vs fsck of the gjournalled drives, I'm fairly sure. > >> Wow, thats a setup. > > More an artifact of fair old age and accretion than design... > >> I have a few more questions. >> >> Your first email, you mentioned gjournal overflow panics. Have you fixed= that? > > No: I've avoided it, at risk of incomplete backups, by leaving > the -L (snapshot) option off my backup "dump" calls. =A0I'm fairly > certain that I can generate those panics on demand, now that I > know what's causing them. =A0(I prefer not to, of course, this > machine is in constant use.) > >> I see you are gmirroring the slices, when you did the gmirror + >> gjournal slice, did you check the bsdlabel? sometimes it doesn't >> report the right block size, and the disk + journal overlap. I had >> this happen to me on my first setup which resulted in the overflow >> panics. > > Not sure about that. =A0All of my disks only have one bsdlabel, on > the raw provider. =A0I fdisk -BI; bsdlabel -w -B and then newfs > the ...s1a partition, as a general rule. =A0Now that I'm running > gjournal, that's fdisk; bsdlabel; gjournal label ...; newfs > ...s1a.journal. =A0There isn't a label between the gjournal and > the file system. > > In the case of my main, gmirrored disk pair, I bsdlabel -e'd > after the "use whole disk" standard procedure and made liberal > use of "*" wildcards to make sure that bsdlabel did the right > thing. =A0I was *very* glad when I didn't have to muck about > calculating sector offsets any more. > > I have my mirror'd pair layered: fdisk; bsdlabel; gmirror on > ad[46]s1a, ad[46]s1d and ad[46]s1e, separately, rather than > mirroring the raw ad4/ad6 pair and then bsdlabeling the > resulting mirror because I couldn't see the point in swapping to > a mirror. =A0So I swap to ad4s1b and ad6s1b independently. =A0So I > have root on mirror/gm0a (no soft-updates), var on mirror/gm0d > (with soft-updates), and a gjournal on mirror/gm0e, with a newfs > -J partition on mirror/gm0e.journal > >> Its not as easy as a >> gmirror label ... >> gjournal label ... >> You gotta check the bsdlabel each time to make sure the c slice and >> additional slices are the correct size. > > I didn't think that GEOM layers needed to have a bsdlabel each, > and newfs is happy enough (I think) to sit on an unlabelled GEOM > provider. =A0Certainly the examples in the gjournal, gmirror and > mdconfig man pages seem to suggest that newfs'ing straight onto > one of them is the way to go. > >> If you do decide to do it again, gpt made it really easy. > > What's a gpt? =A0Neither man nor bash know about it on my system. > >> Did you use newfs -J to format the slices/journal? > > Yup. > > Thanks for the help and suggestions! > > Cheers, > > -- > Andrew > Can you show me a print out of gjournal list and bsdlabel /dev/mirror/gm0e.journal And any other .journal you have Just want to double check something. Regards David N From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 09:50:57 2010 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 CB4391065670 for ; Wed, 21 Apr 2010 09:50:57 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas02p.mx.bigpond.com (nschwmtas02p.mx.bigpond.com [61.9.189.140]) by mx1.freebsd.org (Postfix) with ESMTP id 51C308FC21 for ; Wed, 21 Apr 2010 09:50:56 +0000 (UTC) Received: from nschwotgx01p.mx.bigpond.com ([124.188.161.100]) by nschwmtas02p.mx.bigpond.com (InterMail vM.7.05.02.08 201-2174-114-118-20080528) with ESMTP id <20100421095055.GJTE28300.nschwmtas02p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com>; Wed, 21 Apr 2010 09:50:55 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20100421095054.FCAI3673.nschwotgx01p.mx.bigpond.com@duncan.reilly.home>; Wed, 21 Apr 2010 09:50:54 +0000 Date: Wed, 21 Apr 2010 19:50:54 +1000 From: Andrew Reilly To: David N Message-ID: <20100421095054.GA28619@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx01p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Wed, 21 Apr 2010 09:50:54 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4BCECA7F.0023,ss=1,fgs=0 X-SIH-MSG-ID: qh0yEN38TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRsM6kxDxNJhqMNGQgaanhTY3Rs9mK Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 09:50:58 -0000 Hi David, On Wed, Apr 21, 2010 at 07:16:08PM +1000, David N wrote: > Can you show me a print out of > gjournal list here: Geom name: gjournal 827322917 ID: 827322917 Providers: 1. Name: mirror/gm0e.journal Mediasize: 981949479936 (915G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: mirror/gm0e Mediasize: 983023222272 (916G) Sectorsize: 512 Mode: r1w1e1 Jend: 983023221760 Jstart: 981949479936 Role: Data,Journal Geom name: gjournal 1843456033 ID: 1843456033 Providers: 1. Name: ad8s1a.journal Mediasize: 1499228127232 (1.4T) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ad8s1a Mediasize: 1500301869568 (1.4T) Sectorsize: 512 Mode: r1w1e1 Jend: 1500301869056 Jstart: 1499228127232 Role: Data,Journal Geom name: gjournal 3015273731 ID: 3015273731 Providers: 1. Name: ad10s1.journal Mediasize: 749081051136 (698G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ad10s1 Mediasize: 750154793472 (699G) Sectorsize: 512 Mode: r1w1e1 Jend: 750154792960 Jstart: 749081051136 Role: Data,Journal > and > bsdlabel /dev/mirror/gm0e.journal duncan [201]$ bsdlabel mirror/gm0e.journal bsdlabel: /dev/mirror/gm0e.journal: no valid label found > And any other .journal you have duncan [202]$ bsdlabel ad8s1a.journal bsdlabel: /dev/ad8s1a.journal: no valid label found duncan [203]$ bsdlabel ad10s1.journal # /dev/ad10s1.journal: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1465146065 16 unused 0 0 c: 1465146081 0 unused 0 0 # "raw" part, don't edit partition a: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities Hmm. That's a bit surprising. I'm fairly certain that I didn't label ad10s1.journal, but that disk has been used for other things before, and the partition label is the the same (but without the warnings): duncan [204]$ bsdlabel ad10s1 # /dev/ad10s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1465146065 16 unused 0 0 c: 1465146081 0 unused 0 0 # "raw" part, don't edit I guess I should have nuked the starting sectors a bit more thoroughly? That isn't the disk that's giving me panics though. > Just want to double check something. Hope that helps! Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 10:09:24 2010 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 D6A9D1065670 for ; Wed, 21 Apr 2010 10:09:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4FD8FC08 for ; Wed, 21 Apr 2010 10:09:23 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id 89ht1e0071ap0As51A9QVm; Wed, 21 Apr 2010 10:09:24 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.westchester.pa.mail.comcast.net with comcast id 8ACi1e0033S48mS3iACjEW; Wed, 21 Apr 2010 10:12:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1E06E9B419; Wed, 21 Apr 2010 03:09:22 -0700 (PDT) Date: Wed, 21 Apr 2010 03:09:22 -0700 From: Jeremy Chadwick To: Andrew Reilly Message-ID: <20100421100922.GA95130@icarus.home.lan> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> <20100421095054.GA28619@duncan.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100421095054.GA28619@duncan.reilly.home> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 10:09:24 -0000 On Wed, Apr 21, 2010 at 07:50:54PM +1000, Andrew Reilly wrote: > duncan [203]$ bsdlabel ad10s1.journal > # /dev/ad10s1.journal: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 1465146065 16 unused 0 0 > c: 1465146081 0 unused 0 0 # "raw" part, don't edit > partition a: partition extends past end of unit > partition c: partition extends past end of unit > bsdlabel: partition c doesn't cover the whole unit! > bsdlabel: An incorrect partition c may cause problems for standard system utilities > > Hmm. That's a bit surprising. I'm fairly certain that I didn't > label ad10s1.journal, but that disk has been used for other > things before, and the partition label is the the same (but > without the warnings): Ignore this error. This error also appears (probably on non-journalled slices) as "Disk geometry does not match label!" during boot. Your disks were bsdlabel'd before a GEOM change that changes the offset of slice "a". Case in point (a system which had its disks labelled *after* the above change): # bsdlabel ada0s1 # /dev/ada0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 0 4.2BSD 0 0 0 b: 25165824 2097152 swap c: 78165297 0 unused 0 0 # "raw" part, don't edit d: 25165824 27262976 4.2BSD 0 0 0 e: 8388608 52428800 4.2BSD 0 0 0 f: 17347889 60817408 4.2BSD 0 0 0 -- | 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 Apr 21 11:47:33 2010 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 77EFB1065679 for ; Wed, 21 Apr 2010 11:47:33 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8E08FC1A for ; Wed, 21 Apr 2010 11:47:32 +0000 (UTC) Received: by qyk11 with SMTP id 11so8013921qyk.13 for ; Wed, 21 Apr 2010 04:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sELrYAKsbsUgPOEUjnmz1Pv/Wxi/OoJcTF69I8p1RYQ=; b=IfBiSgtO1flilOn6LQWcy5Enev1QbQkpZ8Io7QYd47qCA4u/bkcXDQIBdIfj7FEeqp hxsDydD4LTSeLiDGW+2syQxdIGYhjh7gT53ce53BeQlR0diZddObN1NaPMCCqKqxz3Pp TEN1YJ9Ib2B5AuwVxVTGR7q2yW75KCQCfa2HU= 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=uG3r6Zom9ML30EQ2yjBSnBnyHSchdJDVW6aZhpqLjENyT8Y6jphGs8ML0lpVUrUido avyXHaWP3mQ+Xb1NRK+IQyHZqpYA9PA2oqTl1rOKU0dLMQh0wTbvJr5dbgFK3gPM2c/E yq8gbmP9IJ4u4XfY2eYJoa0OFGhg5zL8lRFGQ= MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Wed, 21 Apr 2010 04:47:32 -0700 (PDT) In-Reply-To: <20100421095054.GA28619@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> <20100421095054.GA28619@duncan.reilly.home> Date: Wed, 21 Apr 2010 21:47:32 +1000 Received: by 10.229.213.140 with SMTP id gw12mr262995qcb.96.1271850452255; Wed, 21 Apr 2010 04:47:32 -0700 (PDT) Message-ID: From: David N To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 21 Apr 2010 11:47:33 -0000 On 21 April 2010 19:50, Andrew Reilly wrote: > Hi David, > > On Wed, Apr 21, 2010 at 07:16:08PM +1000, David N wrote: >> Can you show me a print out of >> gjournal list > > here: > > > Geom name: gjournal 827322917 > ID: 827322917 > Providers: > 1. Name: mirror/gm0e.journal > =A0 Mediasize: 981949479936 (915G) > =A0 Sectorsize: 512 > =A0 Mode: r1w1e1 > Consumers: > 1. Name: mirror/gm0e > =A0 Mediasize: 983023222272 (916G) > =A0 Sectorsize: 512 > =A0 Mode: r1w1e1 > =A0 Jend: 983023221760 > =A0 Jstart: 981949479936 > =A0 Role: Data,Journal > > Geom name: gjournal 1843456033 > ID: 1843456033 > Providers: > 1. Name: ad8s1a.journal > =A0 Mediasize: 1499228127232 (1.4T) > =A0 Sectorsize: 512 > =A0 Mode: r1w1e1 > Consumers: > 1. Name: ad8s1a > =A0 Mediasize: 1500301869568 (1.4T) > =A0 Sectorsize: 512 > =A0 Mode: r1w1e1 > =A0 Jend: 1500301869056 > =A0 Jstart: 1499228127232 > =A0 Role: Data,Journal > > Geom name: gjournal 3015273731 > ID: 3015273731 > Providers: > 1. Name: ad10s1.journal > =A0 Mediasize: 749081051136 (698G) > =A0 Sectorsize: 512 > =A0 Mode: r1w1e1 > Consumers: > 1. Name: ad10s1 > =A0 Mediasize: 750154793472 (699G) > =A0 Sectorsize: 512 > =A0 Mode: r1w1e1 > =A0 Jend: 750154792960 > =A0 Jstart: 749081051136 > =A0 Role: Data,Journal > > >> and >> bsdlabel /dev/mirror/gm0e.journal > > duncan [201]$ bsdlabel mirror/gm0e.journal > bsdlabel: /dev/mirror/gm0e.journal: no valid label found > >> And any other .journal you have > > duncan [202]$ bsdlabel ad8s1a.journal > bsdlabel: /dev/ad8s1a.journal: no valid label found > duncan [203]$ bsdlabel ad10s1.journal > # /dev/ad10s1.journal: > 8 partitions: > # =A0 =A0 =A0 =A0size =A0 offset =A0 =A0fstype =A0 [fsize bsize bps/cpg] > =A0a: 1465146065 =A0 =A0 =A0 16 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 0 > =A0c: 1465146081 =A0 =A0 =A0 =A00 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 = 0 =A0 =A0 =A0 =A0 # "raw" part, don't edit > partition a: partition extends past end of unit > partition c: partition extends past end of unit > bsdlabel: partition c doesn't cover the whole unit! > bsdlabel: An incorrect partition c may cause problems for standard system= utilities > > Hmm. =A0That's a bit surprising. =A0I'm fairly certain that I didn't > label ad10s1.journal, but that disk has been used for other > things before, and the partition label is the the same (but > without the warnings): > > duncan [204]$ bsdlabel ad10s1 > # /dev/ad10s1: > 8 partitions: > # =A0 =A0 =A0 =A0size =A0 offset =A0 =A0fstype =A0 [fsize bsize bps/cpg] > =A0a: 1465146065 =A0 =A0 =A0 16 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 0 > =A0c: 1465146081 =A0 =A0 =A0 =A00 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 = 0 =A0 =A0 =A0 =A0 # "raw" part, don't edit > > I guess I should have nuked the starting sectors a bit more > thoroughly? > > That isn't the disk that's giving me panics though. > >> Just want to double check something. > > Hope that helps! > > Cheers, > > -- > Andrew > > Sorry, i forgot the gm0e and ad8s1a is a label. can you show me the bsdlabel for the mirror/gm0 and ad8s1 Also there is a overflow with the ad10s1 and journal Geom name: gjournal 3015273731 ID: 3015273731 Providers: 1. Name: ad10s1.journal Mediasize: 749081051136 (698G) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: ad10s1 Mediasize: 750154793472 (699G) Sectorsize: 512 Mode: r1w1e1 Jend: 750154792960 Jstart: 749081051136 Role: Data,Journal duncan [204]$ bsdlabel ad10s1 # /dev/ad10s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1465146065 16 unused 0 0 c: 1465146081 0 unused 0 0 # "raw" part, don't edit partition a: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities When i first started, it kept complaining. For slices, you have the ad10, put the s1 slice in, then you gjournal that, bsdlabel the .journal. Then change the label to the mediasize of the journal/512. So in your case your bsdlabel should be 749081051136 / 512 =3D 1463048928 with offset of 0. c: 1465146081 - (what is expected)1463048928 =3D 2097153*512 =3D 1073742336 (which is roughly 1GB, your journal size) Your c label is over by about 1GB which means the fs is writing over the journal part sometimes and the journal writing over the data sometimes, which would lead to the journal overflow and journal/data corruption. I hope i haven't confused you. I started to gjournal the slices as gjournalling the bsdlabels you needed to decrease your bsdlabel by 1 (thats where the GEOM data was stored) and gave me too many headaches. If you gjournal the slices, then bsdlabel them, you just change the c label to (.journal media size)/512 offset 0, and it all works. Regards David N From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 13:04:41 2010 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 4B7281065679 for ; Wed, 21 Apr 2010 13:04:41 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id F26F08FC13 for ; Wed, 21 Apr 2010 13:04:40 +0000 (UTC) Received: by qyk11 with SMTP id 11so8113933qyk.13 for ; Wed, 21 Apr 2010 06:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=SGgVBKGBXlEdUgrACQW+22rW/kZ/yvjPl0eFMmCdq7Q=; b=t968tDLwK4b3tZn98JPB6x/g0iXNaISNh4ES4DbYftGO9a5PAiKxZNhjxLWcRJPCHS gbwR7iwPW/2B0EYaut5DsCzYWoahDtOnbxlYLWrlw19DLBCohVS8F6I8Tk1qtlwMPsrw FYpRW9PcxcqE+sTAXjZu83lJ4amxT9JI4+z0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wfNm3WxC3WenEE3SqMm8yCn4+b1l6nxaXbYXMT9IFbkkmwB6ietn36AmK28JwVMM0V HlVEmHFmR71h5uMzVWWKEETIm0goMnTGQCIKx2m/uobuNSCXxJstslWWPT0FrSZuTBZq Y+82T2X7mBudDwJH5X28xdJmRIfRB0dEAjigM= Received: by 10.224.14.18 with SMTP id e18mr2756320qaa.99.1271855080020; Wed, 21 Apr 2010 06:04:40 -0700 (PDT) Received: from centel.dataix.local (c-71-205-129-194.hsd1.mi.comcast.net [71.205.129.194]) by mx.google.com with ESMTPS id 7sm2317134qwb.44.2010.04.21.06.04.38 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 06:04:38 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BCEF7E4.6080606@dataix.net> Date: Wed, 21 Apr 2010 09:04:36 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andriy Gapon References: <4BC86CF3.7060708@icyb.net.ua> In-Reply-To: <4BC86CF3.7060708@icyb.net.ua> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: some arc_reclaim_needed stats 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, 21 Apr 2010 13:04:41 -0000 On 04/16/2010 09:58, Andriy Gapon wrote: > > I added some statistics gathering code to arc_reclaim_needed (see a diff below) > and got these results: > > vfs.zfs.arc_reclaim_kmem_used: 192 > vfs.zfs.arc_reclaim_paging_target: 72505 > vfs.zfs.arc_reclaim_pages_needed: 17 > vfs.zfs.arc_reclaim_arc_c_max: 150 > vfs.zfs.arc_reclaim_needfree: 1693 > > Are these numbers useful in any way? :-) > What do they tell? > Perhaps vm_paging_target() check is a bit too aggressive? > > Thanks! > > > diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > index ca8ffb1..6db69e1 100644 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c > @@ -2040,6 +2040,24 @@ arc_shrink(void) > > static int needfree = 0; > > +static int arc_reclaim_needfree = 0; > +static int arc_reclaim_arc_c_max = 0; > +static int arc_reclaim_pages_needed = 0; > +static int arc_reclaim_paging_target = 0; > +static int arc_reclaim_kmem_used = 0; > + > +SYSCTL_INT(_vfs_zfs, OID_AUTO, arc_reclaim_needfree, CTLFLAG_RD, > + &arc_reclaim_needfree, 0, "Later"); > +SYSCTL_INT(_vfs_zfs, OID_AUTO, arc_reclaim_arc_c_max, CTLFLAG_RD, > + &arc_reclaim_arc_c_max, 0, "Later"); > +SYSCTL_INT(_vfs_zfs, OID_AUTO, arc_reclaim_pages_needed, CTLFLAG_RD, > + &arc_reclaim_pages_needed, 0, "Later"); > +SYSCTL_INT(_vfs_zfs, OID_AUTO, arc_reclaim_paging_target, CTLFLAG_RD, > + &arc_reclaim_paging_target, 0, "Later"); > +SYSCTL_INT(_vfs_zfs, OID_AUTO, arc_reclaim_kmem_used, CTLFLAG_RD, > + &arc_reclaim_kmem_used, 0, "Later"); > + > +/* XXX AVG ZFS BOOKMARK */ > static int > arc_reclaim_needed(void) > { > @@ -2048,10 +2066,14 @@ arc_reclaim_needed(void) > #endif > > #ifdef _KERNEL > - if (needfree) > + if (needfree) { > + arc_reclaim_needfree++; > return (1); > - if (arc_size > arc_c_max) > + } > + if (arc_size > arc_c_max) { > + arc_reclaim_arc_c_max++; > return (1); > + } > if (arc_size <= arc_c_min) > return (0); > > @@ -2059,8 +2081,14 @@ arc_reclaim_needed(void) > * If pages are needed or we're within 2048 pages > * of needing to page need to reclaim > */ > - if (vm_pages_needed || (vm_paging_target() > -2048)) > + if (vm_pages_needed) { > + arc_reclaim_pages_needed++; > + return (1); > + } > + if ((vm_paging_target() > -2048)) { > + arc_reclaim_paging_target++; > return (1); > + } > > #if 0 > /* > @@ -2105,8 +2133,10 @@ arc_reclaim_needed(void) > return (1); > #endif > #else > - if (kmem_used() > (kmem_size() * 3) / 4) > + if (kmem_used() > (kmem_size() * 3) / 4) { > + arc_reclaim_kmem_used++; > return (1); > + } > #endif > > #else > Hi Andriy, If these are not tunable values and serve a good purpose as a stat to be added at some point, would they not be better in kstat.zfs.misc? rather than vfs.zfs so they can be collected with the rest of the stats via arc_summary.pl. Without seeing the thread "kstat.zfs.misc.arcstats.hash_collisions" I had updated the arc_summary.pl script yesterday to include these under a "ARC Misc" section in the output. Just a FYI in case it may be useful to you or others. Thanks PS: Not a must, but anything that is ZFS (k)stats related I would appreciate greatly being CC'd so I can properly track the improvements and adjust the arc_summary.pl script appropriately. Regards, -- http://jhell.googlecode.com/files/arc_summary.pl (r59) jhell From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 14:45:14 2010 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 D77CF1065673 for ; Wed, 21 Apr 2010 14:45:14 +0000 (UTC) (envelope-from davide.damico@gmail.com) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by mx1.freebsd.org (Postfix) with ESMTP id 6911B8FC23 for ; Wed, 21 Apr 2010 14:45:14 +0000 (UTC) Received: by bwz28 with SMTP id 28so8288290bwz.14 for ; Wed, 21 Apr 2010 07:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type:content-transfer-encoding; bh=iqgrhXn8+PHDqZ531jUYYZ4YMi8492OzrHDRvY0OKQI=; b=JGyZk7AHZTmOkHpeFm8APXWvoUn2O0BIEw/cVINRvKzsbwcka/Ql8LQ1QwRLS/n7Fr CpnKTOuaar6vq+r3HREiEv7b3mbcP4nHDQQhKtrYuN/lOzvbfrxodroXBaCMJM0/W48S tldFx1BDQv6uIydHlinp7aQERVRQH8P72fdds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=Y1hX7glFNZFQ7MLDIZ/invtgyIYzdi7SNB2kLggeRnHpcAkhlyllRzyA+DqsCtVhOp 3Zu+9mRemXlLwhlooIyiELRL4zTmcn1c8Lxe2VqTI98z0T0SlmO5GoV8oHCvb+eNHped 1jNYV1FZAJqs9rBrq5S8rcB63aawvMAF5eR3E= MIME-Version: 1.0 Received: by 10.204.121.129 with HTTP; Wed, 21 Apr 2010 07:44:53 -0700 (PDT) From: "Davide D'Amico" Date: Wed, 21 Apr 2010 16:44:53 +0200 Received: by 10.204.36.208 with SMTP id u16mr7272790bkd.168.1271861113132; Wed, 21 Apr 2010 07:45:13 -0700 (PDT) Message-ID: To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: HAST, ZFS and CARP [Re: freebsd-fs Digest, Vol 357, Issue 3] 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, 21 Apr 2010 14:45:14 -0000 > Message: 3 > Date: Tue, 20 Apr 2010 07:39:43 -0700 > From: Freddie Cash > Subject: Re: HAST and ZFS > To: freebsd-fs@freebsd.org > Message-ID: > =A0 =A0 =A0 =A0 > Content-Type: text/plain; charset=3DUTF-8 > > On Tue, Apr 20, 2010 at 7:24 AM, Davide D'Amico = wrote: > >> I'm trying to setup an active/passive cluster. >> Some questions: >> - why the use of net/ucarp rather than carp? Is it for its up/down scrip= ts? >> - I would like to use ZFS on top on HAST, so I think that in >> wiki.freebsd.org/HAST >> I should change UFS (in sh scripts) but how to replace newfs command? >> With zpool create disk da0? >> > > See the mailing list archives. =A0I posted a devd.conf and script for usi= ng > CARP instead of uCARP, for using HAST devices to create a ZFS pool. =A0Wo= rks > quite nicely, although there are no checks/fixes to prevent split-brain i= f > CARP flip-flops between the two hosts. Hi, I've read the mailling list archives (lists.freebsd.org give me an internal server error), and I've successfully created a failover cluster using hast, zfs and carp. I tried to shutdown the primary node, and than I see on he secondary node: Apr 21 15:27:45 hastb hastd: Connection from tcp4://10.8.0.3:8457 to tcp4://10.8.0.3:55949. Apr 21 15:27:45 hastb hastd: [da0s2] (primary) We act as primary for the resource and not as secondary as requested by tcp4://10.8.0.3:55949. Apr 21 15:27:45 hastb hastd: [da0s2] (primary) Remote node acts as primary for the resource and not as secondary. How could I resolve these issues? Thanks, d. From owner-freebsd-fs@FreeBSD.ORG Wed Apr 21 19:50:03 2010 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 87AAC1065679 for ; Wed, 21 Apr 2010 19:50:03 +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 753AE8FC08 for ; Wed, 21 Apr 2010 19:50:03 +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 o3LJo3r6088990 for ; Wed, 21 Apr 2010 19:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3LJo3Dp088989; Wed, 21 Apr 2010 19:50:03 GMT (envelope-from gnats) Date: Wed, 21 Apr 2010 19:50:03 GMT Message-Id: <201004211950.o3LJo3Dp088989@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Alex Bakhtin Cc: Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Bakhtin List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 19:50:03 -0000 The following reply was made to PR kern/145339; it has been noted by GNATS. From: Alex Bakhtin To: Andriy Gapon Cc: bug-followup@freebsd.org, Pawel Jakub Dawidek Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool Date: Wed, 21 Apr 2010 23:42:20 +0400 Andriy, Sorry for delay, gmail put your mail into spam folder. > Are you sure that this is a deadlock? Sorry, the problem description seems to be not 100 percent clear. > If yes, could you please describe what you see in more details. On GENERIC I discovered a deadlock when I detach device from raidz pool if there is intensive writing to the pool. The box responds to pings but doesn't respond to power button (ACPI request ignored). I built kernel with the following config: > cat /sys/amd64/conf/DEBUG include GENERIC ident DEBUG options ALT_BREAK_TO_DEBUGGER options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC options KDB options DDB options INCLUDE_CONFIG_FILE and got this crash. After looking into crashinfo I assumed that it crashes in _mtx_lock_flags because of debugging options (as I can see - there are many asserts in this function) but probably I'm wrong. I checked /mnt/crash directory and discovered that there is a full crash info gathered by sysutils/bsdcrashtar. Probably, this info could help to find the root cause? tar tvzf crash.10.tar.gz drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/ lrwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/machine -> usr/src.old/sys/amd64/include drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/mnt/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/boot/ -rwxr-xr-x 0 root wheel 211 Apr 3 06:13 crash.10/debug.sh -rw-r--r-- 0 root wheel 50 Apr 3 06:13 crash.10/README drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/boot/kernel/ -r-xr-xr-x 0 root wheel 12581947 Apr 3 06:13 crash.10/boot/kernel/kernel -r-xr-xr-x 0 root wheel 44335787 Apr 3 06:13 crash.10/boot/kernel/kernel.symbols -r-xr-xr-x 0 root wheel 1532664 Apr 3 06:13 crash.10/boot/kernel/zfs.ko -r-xr-xr-x 0 root wheel 12693960 Apr 3 06:13 crash.10/boot/kernel/zfs.ko.symbols -r-xr-xr-x 0 root wheel 9832 Apr 3 06:13 crash.10/boot/kernel/opensolaris.ko -r-xr-xr-x 0 root wheel 145808 Apr 3 06:13 crash.10/boot/kernel/opensolaris.ko.symbols -r-xr-xr-x 0 root wheel 146048 Apr 3 06:13 crash.10/boot/kernel/geom_mirror.ko -r-xr-xr-x 0 root wheel 314512 Apr 3 06:13 crash.10/boot/kernel/geom_mirror.ko.symbols drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cam/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/ddb/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/dev/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/fs/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/geom/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/kern/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/modules/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/net/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/nfs/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/nfsserver/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/rpc/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/security/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/sys/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/ufs/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/vm/ -rw-r--r-- 0 root wheel 83274 Apr 3 06:13 crash.10/usr/src.old/sys/vm/uma_core.c -rw-r--r-- 0 root wheel 26799 Apr 3 06:13 crash.10/usr/src.old/sys/vm/vm_glue.c -rw-r--r-- 0 root wheel 104178 Apr 3 06:13 crash.10/usr/src.old/sys/vm/vm_map.c -rw-r--r-- 0 root wheel 45074 Apr 3 06:13 crash.10/usr/src.old/sys/vm/vm_pageout.c -rw-r--r-- 0 root wheel 4978 Apr 3 06:13 crash.10/usr/src.old/sys/vm/vm_zeroidle.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/ufs/ffs/ -rw-r--r-- 0 root wheel 189645 Apr 3 06:13 crash.10/usr/src.old/sys/ufs/ffs/ffs_softdep.c -rw-r--r-- 0 root wheel 18465 Apr 3 06:13 crash.10/usr/src.old/sys/sys/buf.h -rw-r--r-- 0 root wheel 8941 Apr 3 06:13 crash.10/usr/src.old/sys/sys/file.h -rw-r--r-- 0 root wheel 32408 Apr 3 06:13 crash.10/usr/src.old/sys/sys/mbuf.h drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/security/audit/ -rw-r--r-- 0 root wheel 15538 Apr 3 06:13 crash.10/usr/src.old/sys/security/audit/audit_worker.c -rw-r--r-- 0 root wheel 30942 Apr 3 06:13 crash.10/usr/src.old/sys/rpc/svc.c -rw-r--r-- 0 root wheel 13440 Apr 3 06:13 crash.10/usr/src.old/sys/nfsserver/nfs_srvkrpc.c -rw-r--r-- 0 root wheel 4928 Apr 3 06:13 crash.10/usr/src.old/sys/nfs/nfs_nfssvc.c -rw-r--r-- 0 root wheel 45178 Apr 3 06:13 crash.10/usr/src.old/sys/net/flowtable.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/compat/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ -rw-r--r-- 0 root wheel 129959 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c -rw-r--r-- 0 root wheel 17453 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c -rw-r--r-- 0 root wheel 112698 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c -rw-r--r-- 0 root wheel 15102 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c -rw-r--r-- 0 root wheel 15178 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c -rw-r--r-- 0 root wheel 120600 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c -rw-r--r-- 0 root wheel 63052 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/compat/opensolaris/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/compat/opensolaris/kern/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/compat/opensolaris/sys/ -rw-r--r-- 0 root wheel 3843 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/compat/opensolaris/sys/atomic.h -rw-r--r-- 0 root wheel 3673 Apr 3 06:13 crash.10/usr/src.old/sys/cddl/compat/opensolaris/kern/opensolaris_taskq.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/modules/zfs/ -rw-r--r-- 0 root wheel 21756 Apr 3 06:13 crash.10/usr/src.old/sys/kern/init_main.c -rw-r--r-- 0 root wheel 11706 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_condvar.c -rw-r--r-- 0 root wheel 24056 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_exit.c -rw-r--r-- 0 root wheel 22111 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_fork.c -rw-r--r-- 0 root wheel 46996 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_intr.c -rw-r--r-- 0 root wheel 25236 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_malloc.c -rw-r--r-- 0 root wheel 23736 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_mutex.c -rw-r--r-- 0 root wheel 79669 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_sig.c -rw-r--r-- 0 root wheel 15720 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_synch.c -rw-r--r-- 0 root wheel 36031 Apr 3 06:13 crash.10/usr/src.old/sys/kern/kern_time.c -rw-r--r-- 0 root wheel 71672 Apr 3 06:13 crash.10/usr/src.old/sys/kern/sched_ule.c -rw-r--r-- 0 root wheel 12187 Apr 3 06:13 crash.10/usr/src.old/sys/kern/subr_kdb.c -rw-r--r-- 0 root wheel 33114 Apr 3 06:13 crash.10/usr/src.old/sys/kern/subr_sleepqueue.c -rw-r--r-- 0 root wheel 10565 Apr 3 06:13 crash.10/usr/src.old/sys/kern/subr_taskqueue.c -rw-r--r-- 0 root wheel 34998 Apr 3 06:13 crash.10/usr/src.old/sys/kern/sys_generic.c -rw-r--r-- 0 root wheel 48706 Apr 3 06:13 crash.10/usr/src.old/sys/kern/tty.c -rw-r--r-- 0 root wheel 28015 Apr 3 06:13 crash.10/usr/src.old/sys/kern/tty_ttydisc.c -rw-r--r-- 0 root wheel 93141 Apr 3 06:13 crash.10/usr/src.old/sys/kern/uipc_socket.c -rw-r--r-- 0 root wheel 109887 Apr 3 06:13 crash.10/usr/src.old/sys/kern/vfs_bio.c -rw-r--r-- 0 root wheel 110274 Apr 3 06:13 crash.10/usr/src.old/sys/kern/vfs_subr.c -rw-r--r-- 0 root wheel 19944 Apr 3 06:13 crash.10/usr/src.old/sys/geom/geom_io.c -rw-r--r-- 0 root wheel 6915 Apr 3 06:13 crash.10/usr/src.old/sys/geom/geom_kern.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/fs/devfs/ -rw-r--r-- 0 root wheel 36833 Apr 3 06:13 crash.10/usr/src.old/sys/fs/devfs/devfs_vnops.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/dev/fdc/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/dev/md/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/dev/random/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/dev/usb/ -rw-r--r-- 0 root wheel 13618 Apr 3 06:13 crash.10/usr/src.old/sys/dev/usb/usb_process.c -rw-r--r-- 0 root wheel 11623 Apr 3 06:13 crash.10/usr/src.old/sys/dev/random/randomdev_soft.c -rw-r--r-- 0 root wheel 31483 Apr 3 06:13 crash.10/usr/src.old/sys/dev/md/md.c -rw-r--r-- 0 root wheel 49685 Apr 3 06:13 crash.10/usr/src.old/sys/dev/fdc/fdc.c -rw-r--r-- 0 root wheel 17269 Apr 3 06:13 crash.10/usr/src.old/sys/ddb/db_command.c -rw-r--r-- 0 root wheel 6005 Apr 3 06:13 crash.10/usr/src.old/sys/ddb/db_main.c -rw-r--r-- 0 root wheel 15802 Apr 3 06:13 crash.10/usr/src.old/sys/ddb/db_script.c -rw-r--r-- 0 root wheel 125529 Apr 3 06:13 crash.10/usr/src.old/sys/cam/cam_xpt.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/amd64/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pc/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/xen/ -rw-r--r-- 0 root wheel 1848 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/_bus.h -rw-r--r-- 0 root wheel 8622 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/_inttypes.h -rw-r--r-- 0 root wheel 4152 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/_limits.h -rw-r--r-- 0 root wheel 5605 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/_stdint.h -rw-r--r-- 0 root wheel 4437 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/_types.h -rw-r--r-- 0 root wheel 3188 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/acpica_machdep.h -rw-r--r-- 0 root wheel 14393 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/apicreg.h -rw-r--r-- 0 root wheel 9118 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/apicvar.h -rw-r--r-- 0 root wheel 3183 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/asm.h -rw-r--r-- 0 root wheel 7814 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/asmacros.h -rw-r--r-- 0 root wheel 16060 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/atomic.h -rw-r--r-- 0 root wheel 33225 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/bus.h -rw-r--r-- 0 root wheel 1558 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/bus_dma.h -rw-r--r-- 0 root wheel 1036 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/clock.h -rw-r--r-- 0 root wheel 2850 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/cpu.h -rw-r--r-- 0 root wheel 14534 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/cpufunc.h -rw-r--r-- 0 root wheel 2218 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/cputypes.h -rw-r--r-- 0 root wheel 3175 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/db_machdep.h -rw-r--r-- 0 root wheel 3938 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/elf.h -rw-r--r-- 0 root wheel 4572 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/endian.h -rw-r--r-- 0 root wheel 1830 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/exec.h -rw-r--r-- 0 root wheel 3135 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/float.h -rw-r--r-- 0 root wheel 2099 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/floatingpoint.h -rw-r--r-- 0 root wheel 3912 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/fpu.h -rw-r--r-- 0 root wheel 2808 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/frame.h -rw-r--r-- 0 root wheel 1867 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/gdb_machdep.h -rw-r--r-- 0 root wheel 8880 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/ieeefp.h -rw-r--r-- 0 root wheel 2951 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/in_cksum.h -rw-r--r-- 0 root wheel 6089 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/intr_machdep.h -rw-r--r-- 0 root wheel 1503 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/iodev.h -rw-r--r-- 0 root wheel 1914 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/kdb.h -rw-r--r-- 0 root wheel 2462 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/legacyvar.h -rw-r--r-- 0 root wheel 1976 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/limits.h -rw-r--r-- 0 root wheel 1898 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/mca.h -rw-r--r-- 0 root wheel 3753 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/md_var.h -rw-r--r-- 0 root wheel 1605 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/memdev.h -rw-r--r-- 0 root wheel 1629 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/metadata.h -rw-r--r-- 0 root wheel 1769 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/minidump.h -rw-r--r-- 0 root wheel 1595 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/mp_watchdog.h -rw-r--r-- 0 root wheel 3994 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/mptable.h -rw-r--r-- 0 root wheel 1787 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/mutex.h -rw-r--r-- 0 root wheel 1879 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/nexusvar.h -rw-r--r-- 0 root wheel 5770 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/param.h -rw-r--r-- 0 root wheel 3397 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pcb.h -rw-r--r-- 0 root wheel 2023 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pci_cfgreg.h -rw-r--r-- 0 root wheel 7786 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pcpu.h -rw-r--r-- 0 root wheel 10731 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pmap.h -rw-r--r-- 0 root wheel 4236 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pmc_mdep.h -rw-r--r-- 0 root wheel 1949 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/ppireg.h -rw-r--r-- 0 root wheel 2939 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/proc.h -rw-r--r-- 0 root wheel 3710 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/psl.h -rw-r--r-- 0 root wheel 6071 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/profile.h -rw-r--r-- 0 root wheel 1791 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/ptrace.h -rw-r--r-- 0 root wheel 4453 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/reg.h -rw-r--r-- 0 root wheel 2342 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/reloc.h -rw-r--r-- 0 root wheel 1991 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/resource.h -rw-r--r-- 0 root wheel 1918 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/runq.h -rw-r--r-- 0 root wheel 10148 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/segments.h -rw-r--r-- 0 root wheel 2237 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/setjmp.h -rw-r--r-- 0 root wheel 2166 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/sf_buf.h -rw-r--r-- 0 root wheel 1979 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/sigframe.h -rw-r--r-- 0 root wheel 3377 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/signal.h -rw-r--r-- 0 root wheel 2314 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/smp.h -rw-r--r-- 0 root wheel 18029 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/specialreg.h -rw-r--r-- 0 root wheel 1454 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/stack.h -rw-r--r-- 0 root wheel 2647 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/stdarg.h -rw-r--r-- 0 root wheel 3068 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/sysarch.h -rw-r--r-- 0 root wheel 2125 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/timerreg.h -rw-r--r-- 0 root wheel 4008 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/trap.h -rw-r--r-- 0 root wheel 3001 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/tss.h -rw-r--r-- 0 root wheel 3326 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/ucontext.h -rw-r--r-- 0 root wheel 3451 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/varargs.h -rw-r--r-- 0 root wheel 2094 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/vm.h -rw-r--r-- 0 root wheel 7181 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/vmparam.h -rw-r--r-- 0 root wheel 10175 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/xen/hypercall.h -rw-r--r-- 0 root wheel 3418 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/xen/synch_bitops.h -rw-r--r-- 0 root wheel 9309 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/xen/xen-os.h -rw-r--r-- 0 root wheel 2728 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/xen/xenfunc.h -rw-r--r-- 0 root wheel 7859 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/xen/xenpmap.h -rw-r--r-- 0 root wheel 3537 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/xen/xenvar.h -rw-r--r-- 0 root wheel 2791 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pc/bios.h -rw-r--r-- 0 root wheel 1013 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/include/pc/display.h -rw-r--r-- 0 root wheel 21900 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/amd64/exception.S -rw-r--r-- 0 root wheel 3094 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/amd64/locore.S -rw-r--r-- 0 root wheel 35899 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/amd64/mp_machdep.c -rw-r--r-- 0 root wheel 127991 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/amd64/pmap.c -rw-r--r-- 0 root wheel 28692 Apr 3 06:13 crash.10/usr/src.old/sys/amd64/amd64/trap.c drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/mnt/obj/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/mnt/crash/ -rw------- 0 root wheel 3331166208 Apr 3 06:13 crash.10/mnt/crash/vmcore.10 -rw------- 0 root wheel 470 Apr 3 06:13 crash.10/mnt/crash/info.10 drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/mnt/obj/usr/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/mnt/obj/usr/src.old/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/mnt/obj/usr/src.old/sys/ drwxr-xr-x 0 root wheel 0 Apr 3 06:13 crash.10/mnt/obj/usr/src.old/sys/DEBUG/ -rw-r--r-- 0 root wheel 92901 Apr 3 06:13 crash.10/mnt/obj/usr/src.old/sys/DEBUG/vnode_if.c > I am asking because to me it seems like a NULL pointer crash: >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x48 > > It looks like perhaps zio->io_vd became NULL while an I/O response was traveling > up and vdev_geom_io_intr was not prepared to handle that. > >> _mtx_lock_flags() at _mtx_lock_flags+0x39 >> vdev_geom_io_intr() at vdev_geom_io_intr+0x62 >> g_io_schedule_up() at g_io_schedule_up+0xed >> g_up_procbody() at g_up_procbody+0x6f >> fork_exit() at fork_exit+0x12a >> fork_trampoline() at fork_trampoline+0xe If there is any info I can gather on GENERIC - please let me know. The only crashinfo I have is on debug kernel. Alex Bakhtin From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 06:57:02 2010 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 541971065786 for ; Thu, 22 Apr 2010 06:57:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4CB8FC1A for ; Thu, 22 Apr 2010 06:57:01 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A537645E87; Thu, 22 Apr 2010 08:56:58 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 409D645684; Thu, 22 Apr 2010 08:56:52 +0200 (CEST) Date: Thu, 22 Apr 2010 08:56:54 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100422065654.GA2501@garage.freebsd.pl> References: <20100416065126.GG1705@garage.freebsd.pl> <4BCD3979.8050107@soupacific.com> <4BCD5AD7.8070502@soupacific.com> <4BCFA4C2.6000109@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <4BCFA4C2.6000109@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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, 22 Apr 2010 06:57:02 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2010 at 10:22:10AM +0900, hiroshi@soupacific.com wrote: > Thanks pjd ! >=20 > as "Before we start ucarp.sh we have to do some initializations:" > And hast.conf man. >=20 > I put global section into conf then works fine ! >=20 > But when rebooting enabling ucarp then ucarp_up.sh's hastd failed as > [ERROR] Unable to coonect to hastd via /var/run: No such file or director= y.. >=20 > Except conf I copied from examples and modified. Ok, but I asked you to provide your hast.conf. Could you do that? > I hope I fix MX's ip. It is not that, but: : host mail.soupacific.com[211.19.53.202] said: 554 5.7.1 Service unavailable; Client host [83.12.187.60] blocked using dul.dnsbl.sorbs.net; Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?83.12.187.60 (in reply to RCPT TO command) IP address of my mail server is _not_ and never was dynamic. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvP8zYACgkQForvXbEpPzSX3wCfdpEl8l7hx2u7fMDU+lbmX5z+ e+IAoND353CJgaDjsJhBaKinhLhjPsZZ =t8sX -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 09:45:21 2010 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 34EDF106566B for ; Thu, 22 Apr 2010 09:45:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 724D28FC08 for ; Thu, 22 Apr 2010 09:45:17 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0A77245E82; Thu, 22 Apr 2010 11:45:16 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 45BDF456B1; Thu, 22 Apr 2010 11:45:11 +0200 (CEST) Date: Thu, 22 Apr 2010 11:45:13 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100422094513.GA1651@garage.freebsd.pl> References: <20100416065126.GG1705@garage.freebsd.pl> <4BCD3979.8050107@soupacific.com> <4BCD5AD7.8070502@soupacific.com> <4BCFA4C2.6000109@soupacific.com> <4BCFB1C5.5000908@soupacific.com> <4BD01800.9040901@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <4BD01800.9040901@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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, 22 Apr 2010 09:45:21 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2010 at 06:33:52PM +0900, hiroshi@soupacific.com wrote: > The conf file is here. First I read wiki, I understand as simple as=20 > possible. >=20 > #hast.conf > #global section > control /var/run/hastctl > listen tcp4://0.0.0.0 >=20 > #resource section > resource test { > local /dev/da0 > on fw01a { > local /dev/ad6 > remote 10.8.0.2 > } > on fw01b { > local /dev/ad8 > remote 10.8.0.1 > } > } Config looks good. Could you now provide output of the following commands: # pgrep -lf hast # ls -l /var/run/hastctl Could you also paste exact error message you are seeing? What you sent earlier suggests that hastd daemon is not running. If you want to start it during boot, don't forget to add: hastd_enable=3D"YES" to your /etc/rc.conf. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvQGqkACgkQForvXbEpPzRAygCfXxeHjLxRsWk5g+Jq8YatEX6e UUwAoLxC2T1FTkA5OCUfxnHtNNYKTelV =TKd0 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 14:03:48 2010 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 8D0B01065675 for ; Thu, 22 Apr 2010 14:03:48 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id CC6618FC08 for ; Thu, 22 Apr 2010 14:03:47 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 089CB45DF4; Thu, 22 Apr 2010 16:03:46 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 133974569A; Thu, 22 Apr 2010 16:03:41 +0200 (CEST) Date: Thu, 22 Apr 2010 16:03:43 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100422140343.GC1651@garage.freebsd.pl> References: <20100416065126.GG1705@garage.freebsd.pl> <4BCD3979.8050107@soupacific.com> <4BCD5AD7.8070502@soupacific.com> <4BCFA4C2.6000109@soupacific.com> <4BCFB1C5.5000908@soupacific.com> <4BD01800.9040901@soupacific.com> <4BD0438B.5080308@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline In-Reply-To: <4BD0438B.5080308@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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, 22 Apr 2010 14:03:48 -0000 --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 22, 2010 at 09:39:39PM +0900, hiroshi@soupacific.com wrote: > HI! >=20 > > hastd_enable=3D"YES" > >to your /etc/rc.conf. > Sure I put it. >=20 >=20 > I checked following with two condition ! > # pgrep -lf hast > # ls -l /var/run/hastctl >=20 > A. First condition is boot both node. > B. Second only boot first node. >=20 > Condition A works fine ! >=20 > #pgrep -lf hast > 928 hastd: test > (primary) > #ls -l /var/run/hastctl > srwxv -xv -x 1 root wheel 0 Apr 22 22:40 /var/run/hastctl > #ls /dev/hast/test > /dev/hast/test >=20 > Condition B > Error message appears some where during the boot message > hast: Device /dev/hast/test did not appear >=20 > #pgrep -lf hast > 928 hastd: test > (primary) > #ls -l /var/run/hastctl > srwxv -xv -x 1 root wheel 0 Apr 22 xx:xx /var/run/hastctl >=20 > But > #ls /dev/ > hast is not there ! This is expected. GEOM provider will be available only on primary node, because this is where it should be accessed. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --nVMJ2NtxeReIH9PS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvQVz4ACgkQForvXbEpPzQd9ACcDq2mzmb5zj5wRQboR9OE/Bz6 atQAoLZRf4CJ7R8pkDgmEDFqBNuGcEeY =Kv/W -----END PGP SIGNATURE----- --nVMJ2NtxeReIH9PS-- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 14:52:28 2010 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 6B0EB106567B for ; Thu, 22 Apr 2010 14:52:28 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0E8208FC13 for ; Thu, 22 Apr 2010 14:52:27 +0000 (UTC) Received: from wratting.cam.lispworks.com (wratting [192.168.1.17]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with SMTP id o3MEfdQc015214; Thu, 22 Apr 2010 15:41:39 +0100 (BST) (envelope-from martin@lispworks.com) Received: (from martin@localhost) by wratting.cam.lispworks.com (SMI-8.6) id PAA07296; Thu, 22 Apr 2010 15:41:36 +0100 Date: Thu, 22 Apr 2010 15:41:36 +0100 Message-Id: <201004221441.PAA07296@wratting.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org Subject: zfs: unexpected resilver of old disk when attaching a new mirror disk 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, 22 Apr 2010 14:52:28 -0000 When I attach a second disk to a single-disk zpool to make a mirrored pool, the original disk is partially resilvered. Is that expected? It makes me worry that some of the good data is being overwritten. It happens on 8.0-RELEASE (pool version 13) and the 9.0-CURRENT-201004 snapshot (pool version 14). It doesn't happen on Open Solaris snv_111b (also pool version 14). My setup commands for the test, making a 64MB zpool containing a 16MB file are: dd if=/dev/zero of=/tmp/zdisk0 bs=1m count=64 zpool create ztest /tmp/zdisk0 dd if=/dev/zero of=/ztest/a-file bs=1m count=16 The pool looks as expected: pool: ztest state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM ztest ONLINE 0 0 0 /tmp/zdisk0 ONLINE 0 0 0 errors: No known data errors I then attach a second device: dd if=/dev/zero of=/tmp/zdisk1 bs=1m count=64 zpool attach ztest /tmp/zdisk0 /tmp/zdisk1 and the pool looks like this after a while: pool: ztest state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Thu Apr 22 00:29:32 2010 config: NAME STATE READ WRITE CKSUM ztest ONLINE 0 0 0 mirror ONLINE 0 0 0 /tmp/zdisk0 ONLINE 0 0 0 86K resilvered /tmp/zdisk1 ONLINE 0 0 0 16.1M resilvered errors: No known data errors As expected, /tmp/zdisk1 was resilvered with 16MB of data for /ztest/a-file, but why was a small amount of /tmp/zdisk0 also resilvered? The amount varies varies (I've seen up to 220K) but it is never 0. With real disks constaining 5GB, the amount resilvered on the old disk is up to 70MB and it increases gradually from 0 as the resilvering of the new disk proceeds. __Martin From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 15:11:25 2010 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 2CC90106564A for ; Thu, 22 Apr 2010 15:11:25 +0000 (UTC) (envelope-from nowak@xpam.de) Received: from mail.csp-systems.de (mail.csp-systems.de [83.246.83.230]) by mx1.freebsd.org (Postfix) with ESMTP id DA4178FC21 for ; Thu, 22 Apr 2010 15:11:24 +0000 (UTC) Received: by mail.csp-systems.de (Postfix, from userid 602) id 27407693B4D; Thu, 22 Apr 2010 17:11:23 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.csp-systems.de X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=6.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, MISSING_HEADERS,RDNS_NONE autolearn=no version=3.2.5 Received: from master.sinuspl.net (unknown [83.246.67.202]) by mail.csp-systems.de (Postfix) with ESMTP id 8294069001E for ; Thu, 22 Apr 2010 17:11:18 +0200 (CEST) Received: by master.sinuspl.net (Postfix, from userid 8) id 2A98B1080336; Thu, 22 Apr 2010 17:11:18 +0200 (CEST) Received: from [172.19.191.2] (088156221125.bialystok.vectranet.pl [88.156.221.125]) by master.sinuspl.net (Postfix) with ESMTPA id BFBDE10802D7 for ; Thu, 22 Apr 2010 17:11:17 +0200 (CEST) Message-ID: <4BD0670A.8070205@xpam.de> Date: Thu, 22 Apr 2010 17:11:06 +0200 From: Adam Nowacki User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: freebsd-fs@freebsd.org References: <201004221441.PAA07296@wratting.cam.lispworks.com> In-Reply-To: <201004221441.PAA07296@wratting.cam.lispworks.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: zfs: unexpected resilver of old disk when attaching a new mirror disk 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, 22 Apr 2010 15:11:25 -0000 My best guess is metadata updates to refer to the 2nd disk. I've seen same behavior when replacing a bad disk in 10 disk raidz2 pool. No data was affected. Martin Simmons wrote: > When I attach a second disk to a single-disk zpool to make a mirrored pool, > the original disk is partially resilvered. Is that expected? It makes me > worry that some of the good data is being overwritten. > > It happens on 8.0-RELEASE (pool version 13) and the 9.0-CURRENT-201004 > snapshot (pool version 14). It doesn't happen on Open Solaris snv_111b (also > pool version 14). > > My setup commands for the test, making a 64MB zpool containing a 16MB file > are: > > dd if=/dev/zero of=/tmp/zdisk0 bs=1m count=64 > zpool create ztest /tmp/zdisk0 > dd if=/dev/zero of=/ztest/a-file bs=1m count=16 > > The pool looks as expected: > > pool: ztest > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > ztest ONLINE 0 0 0 > /tmp/zdisk0 ONLINE 0 0 0 > > errors: No known data errors > > I then attach a second device: > > dd if=/dev/zero of=/tmp/zdisk1 bs=1m count=64 > zpool attach ztest /tmp/zdisk0 /tmp/zdisk1 > > and the pool looks like this after a while: > > pool: ztest > state: ONLINE > scrub: resilver completed after 0h0m with 0 errors on Thu Apr 22 00:29:32 2010 > config: > > NAME STATE READ WRITE CKSUM > ztest ONLINE 0 0 0 > mirror ONLINE 0 0 0 > /tmp/zdisk0 ONLINE 0 0 0 86K resilvered > /tmp/zdisk1 ONLINE 0 0 0 16.1M resilvered > > errors: No known data errors > > As expected, /tmp/zdisk1 was resilvered with 16MB of data for /ztest/a-file, > but why was a small amount of /tmp/zdisk0 also resilvered? > > The amount varies varies (I've seen up to 220K) but it is never 0. With real > disks constaining 5GB, the amount resilvered on the old disk is up to 70MB and > it increases gradually from 0 as the resilvering of the new disk proceeds. > > __Martin > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 15:20:07 2010 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 4D511106564A for ; Thu, 22 Apr 2010 15:20:07 +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 3CD2A8FC15 for ; Thu, 22 Apr 2010 15: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 o3MFK7H7025909 for ; Thu, 22 Apr 2010 15: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 o3MFK7Uh025906; Thu, 22 Apr 2010 15:20:07 GMT (envelope-from gnats) Date: Thu, 22 Apr 2010 15:20:07 GMT Message-Id: <201004221520.o3MFK7Uh025906@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Steve Polyack Cc: Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steve Polyack List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:20:07 -0000 The following reply was made to PR kern/145339; it has been noted by GNATS. From: Steve Polyack To: bug-followup@FreeBSD.org, Alex.Bakhtin@gmail.com Cc: Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool Date: Thu, 22 Apr 2010 11:13:26 -0400 I've seen a similar issue in the past while testing hot-removal of RAIDZ members (glabeled siis(4)-attached devices). After the /dev/ada* entry would disappear, the /dev/label/diskXX entry would remain and crash shortly down the line with ZFS IO. Here's the panic info in case it is relevant: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 14 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8035f375 stack pointer = 0x28:0xffffff800006db60 frame pointer = 0x28:0xffffff800006db70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2 (g_event) [thread pid 2 tid 100014 ] Stopped at _mtx_lock_flags+0x15: lock cmpxchgq %rsi,0x18(%rdi) db> bt Tracing pid 2 tid 100014 td 0xffffff00014d4ab0 _mtx_lock_flags() at _mtx_lock_flags+0x15 vdev_geom_release() at vdev_geom_release+0x33 vdev_geom_orphan() at vdev_geom_orphan+0x15c g_run_events() at g_run_events+0x104 g_event_procbody() at g_event_procbody+0x55 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800006dd30, rbp = 0 --- From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 17:58:32 2010 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 417E21065670 for ; Thu, 22 Apr 2010 17:58:32 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id D1DD48FC13 for ; Thu, 22 Apr 2010 17:58:31 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX19/evk8VwkVkVD7Dil+/egORU8IiMP5cJ0@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with ESMTP id o3MHwTQc027658; Thu, 22 Apr 2010 18:58:29 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o3MHwTZl006550; Thu, 22 Apr 2010 18:58:29 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o3MHwTb2006547; Thu, 22 Apr 2010 18:58:29 +0100 Date: Thu, 22 Apr 2010 18:58:29 +0100 Message-Id: <201004221758.o3MHwTb2006547@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: <4BD0670A.8070205@xpam.de> (message from Adam Nowacki on Thu, 22 Apr 2010 17:11:06 +0200) References: <201004221441.PAA07296@wratting.cam.lispworks.com> <4BD0670A.8070205@xpam.de> Subject: Re: zfs: unexpected resilver of old disk when attaching a new mirror disk 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, 22 Apr 2010 17:58:32 -0000 >>>>> On Thu, 22 Apr 2010 17:11:06 +0200, Adam Nowacki said: > > My best guess is metadata updates to refer to the 2nd disk. I've seen > same behavior when replacing a bad disk in 10 disk raidz2 pool. No data > was affected. I would expect all new writes to automatically go to all disks though, so they wouldn't be counted as resilvering. __Martin From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 20:55:31 2010 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 A2C871065676 for ; Thu, 22 Apr 2010 20:55:31 +0000 (UTC) (envelope-from scode@scode.org) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 46B1E8FC25 for ; Thu, 22 Apr 2010 20:55:30 +0000 (UTC) Received: by wwa36 with SMTP id 36so5790900wwa.13 for ; Thu, 22 Apr 2010 13:55:30 -0700 (PDT) MIME-Version: 1.0 Sender: scode@scode.org Received: by 10.216.50.11 with HTTP; Thu, 22 Apr 2010 13:55:29 -0700 (PDT) X-Originating-IP: [213.114.159.69] Date: Thu, 22 Apr 2010 22:55:29 +0200 X-Google-Sender-Auth: 245f112a26203885 Received: by 10.216.157.4 with SMTP id n4mr3392437wek.53.1271969729868; Thu, 22 Apr 2010 13:55:29 -0700 (PDT) Message-ID: From: Peter Schuller To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: kern.geom.debugflags=16 does NOT allow me to write to device 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, 22 Apr 2010 20:55:31 -0000 open() in O_RDWR fails on the device in question (which is "used" by glabel, indirectly by gmirror and zfs). This is on an 8.0 userland and 8-STABLE kernel. This is a bit stupid I know (nevermind why), but given that a plain open() syscall is failing I highly doubt that it has anything to do with the userland being out of synch. I cannot imagine GEOM changing like that in between 8.0 and 8-STABLE before the 8.1 release (correct me if this is a poor assumption). Observe: % whoami root % sysctl -w kern.geom.debugflags=16 kern.geom.debugflags: 16 -> 16 % sysctl kern.geom.debugflags kern.geom.debugflags: 16 % ktrace disklabel -B /dev/ad9s1 disklabel: Class not found kdump shows: 15399 disklabel CALL open(0x800c02040,O_RDWR,0xa1a5) 15399 disklabel NAMI "/dev/ad9s1" 15399 disklabel RET open -1 errno 1 Operation not permitted 15399 disklabel CALL open(0x800651b68,O_RDONLY,0) 15399 disklabel NAMI "/dev/geom.ctl" 15399 disklabel RET open 4 15399 disklabel CALL ioctl(0x4,GEOM_CTL,0x800c04040) 15399 disklabel RET ioctl 0 15399 disklabel CALL close(0x4) 15399 disklabel RET close 0 15399 disklabel CALL write(0x2,0x7fffffffde90,0xb) 15399 disklabel GIO fd 2 wrote 11 bytes "disklabel: " 15399 disklabel RET write 11/0xb 15399 disklabel CALL write(0x2,0x7fffffffdf70,0xf) 15399 disklabel GIO fd 2 wrote 15 bytes "Class not found" 15399 disklabel RET write 15/0xf It has these labels: label/prboot1r1 N/A ad9s1a label/prswap1r1 N/A ad9s1b label/prtank1r1 N/A ad9s1d prtank1r1 is part of a ZFS pool. -- / Peter Schuller From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 21:14:25 2010 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 A922B106566C for ; Thu, 22 Apr 2010 21:14:25 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id 6E2788FC0A for ; Thu, 22 Apr 2010 21:14:25 +0000 (UTC) Received: by iwn42 with SMTP id 42so5173537iwn.14 for ; Thu, 22 Apr 2010 14:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=Hy9zN0CdsEq0xqcqpDt/X2Gon9pQxSu7jMnRoRircyc=; b=NGdw/IMGfFD4zkF3d3fZ7yMaMpjlon5KUYTM3B1464ShCJuQgve0xZfp3vJ7rw+V7b zn3r7F1PTtlItsVwAsLN9rN+yuptt4KcKPsd6rCq/IRndzBFtez3SHQkeA1Vhim8IjhT C/okJMrIHtp2MfyripMNGWKG6QJisPCsO8m40= 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=bMEdewzX0V26KEQL8Gyvsxtkj3t4i+efOI27R9AEhDNyPn6Y7/rwOGCGzgZEXmSiQs nM9L2WIfmfufvOiln8o/tiGsHJpWnTw8AKIYNDIm6D7XqIAQs+iVHLBcPVcr4wPtV1wF W9oqIpqsDt9pCbXFuyscGoYIwKnQGl9Y5n5/4= MIME-Version: 1.0 Received: by 10.231.18.74 with HTTP; Thu, 22 Apr 2010 14:14:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Apr 2010 14:14:23 -0700 Received: by 10.231.190.137 with SMTP id di9mr773590ibb.76.1271970864572; Thu, 22 Apr 2010 14:14:24 -0700 (PDT) Message-ID: From: Freddie Cash To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 22 Apr 2010 21:14:25 -0000 On Thu, Apr 22, 2010 at 1:55 PM, Peter Schuller wrote: > open() in O_RDWR fails on the device in question (which is "used" by > glabel, indirectly by gmirror and zfs). > > This is on an 8.0 userland and 8-STABLE kernel. This is a bit stupid I > know (nevermind why), but given that a plain open() syscall is failing > I highly doubt that it has anything to do with the userland being out > of synch. I cannot imagine GEOM changing like that in between 8.0 and > 8-STABLE before the 8.1 release (correct me if this is a poor > assumption). > > Observe: > > % whoami > root > % sysctl -w kern.geom.debugflags=16 > kern.geom.debugflags: 16 -> 16 > % sysctl kern.geom.debugflags > kern.geom.debugflags: 16 > % ktrace disklabel -B /dev/ad9s1 > disklabel: Class not found > > Somewhere in the 7.x -> 8.x transition, debugflags was incremented. You need to set it to 17 now. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 21:14:49 2010 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 6D9901065675 for ; Thu, 22 Apr 2010 21:14:49 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B078C8FC12 for ; Thu, 22 Apr 2010 21:14:48 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA15202; Fri, 23 Apr 2010 00:14:45 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O53jQ-0008Xf-Rl; Fri, 23 Apr 2010 00:14:44 +0300 Message-ID: <4BD0BC44.1040204@icyb.net.ua> Date: Fri, 23 Apr 2010 00:14:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: jhell References: <4BC86CF3.7060708@icyb.net.ua> <4BCEF7E4.6080606@dataix.net> In-Reply-To: <4BCEF7E4.6080606@dataix.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: some arc_reclaim_needed stats 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, 22 Apr 2010 21:14:49 -0000 on 21/04/2010 16:04 jhell said the following: > If these are not tunable values and serve a good purpose as a stat to be > added at some point, would they not be better in kstat.zfs.misc? rather > than vfs.zfs so they can be collected with the rest of the stats via > arc_summary.pl. Yes, I agree. But right now no one seems to think that there is anything useful about these stats :-) > Without seeing the thread "kstat.zfs.misc.arcstats.hash_collisions" I > had updated the arc_summary.pl script yesterday to include these under a > "ARC Misc" section in the output. Just a FYI in case it may be useful to > you or others. BTW, it would be nice if hash table size (number of buckets) would be reported too. But that's a kernel change, not arc_summary. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 21:29:48 2010 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 CF28D106566B for ; Thu, 22 Apr 2010 21:29:48 +0000 (UTC) (envelope-from scode@scode.org) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4C58FC12 for ; Thu, 22 Apr 2010 21:29:47 +0000 (UTC) Received: by wye20 with SMTP id 20so2176192wye.13 for ; Thu, 22 Apr 2010 14:29:46 -0700 (PDT) MIME-Version: 1.0 Sender: scode@scode.org Received: by 10.216.50.11 with HTTP; Thu, 22 Apr 2010 14:29:45 -0700 (PDT) X-Originating-IP: [213.114.159.69] In-Reply-To: References: Date: Thu, 22 Apr 2010 23:29:45 +0200 X-Google-Sender-Auth: 19669f67c44964ff Received: by 10.216.89.74 with SMTP id b52mr1520892wef.142.1271971785751; Thu, 22 Apr 2010 14:29:45 -0700 (PDT) Message-ID: From: Peter Schuller To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 22 Apr 2010 21:29:48 -0000 >> Somewhere in the 7.x -> 8.x transition, debugflags was incremented. =C2= =A0You > need to set it to 17 now. I saw some references to that Googling, but it doesn't work: % sysctl -w kern.geom.debugflags=3D17 prometheus:/tmp(0) kern.geom.debugflags: 17 -> 17 % ktrace disklabel -B /dev/ad9s1 prometheus:/tmp(0) disklabel: Class not found And kdump still shows: 15535 disklabel CALL open(0x800c02040,O_RDWR,0xa1a5) 15535 disklabel NAMI "/dev/ad9s1" 15535 disklabel RET open -1 errno 1 Operation not permitted In addition, geom(4) still has: 0x10 (allow foot shooting) Allow writing to Rank 1 providers. This would, for example, allow the super=E2=80=90user to overwrite the MBR on the root = disk or write random sectors elsewhere to a mounted disk. The implica= =E2=80=90 tions are obvious. In addition, geom/geom_subr.c has: /* If foot-shooting is enabled, any open on rank#1 is OK */ if ((g_debugflags & 16) && pp->geom->rank =3D=3D 1) ; I wonder if the problem is that it's not of rank 1 because I'm writing to the slice's first second rather than the MBR... That's now feeling pretty likely and can perhaps explain lots of confusion that seems to exist based on Googling. Anyone has thoughts on what the proper action here? Or do I need to patch my kernel to update my label? :) (I could pop it out of geom/zfs temporarily and hope the other disk doesn't go. But as a matter of principle I don't want to go that route...) --=20 / Peter Schuller From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 21:35:33 2010 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 10FE11065673 for ; Thu, 22 Apr 2010 21:35:33 +0000 (UTC) (envelope-from scode@scode.org) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id A5A358FC14 for ; Thu, 22 Apr 2010 21:35:32 +0000 (UTC) Received: by wwa36 with SMTP id 36so5816854wwa.13 for ; Thu, 22 Apr 2010 14:35:31 -0700 (PDT) MIME-Version: 1.0 Sender: scode@scode.org Received: by 10.216.50.11 with HTTP; Thu, 22 Apr 2010 14:35:31 -0700 (PDT) X-Originating-IP: [213.114.159.69] In-Reply-To: <4BD0BC44.1040204@icyb.net.ua> References: <4BC86CF3.7060708@icyb.net.ua> <4BCEF7E4.6080606@dataix.net> <4BD0BC44.1040204@icyb.net.ua> Date: Thu, 22 Apr 2010 23:35:31 +0200 X-Google-Sender-Auth: 37bab3b9c52443de Received: by 10.216.157.1 with SMTP id n1mr5772397wek.141.1271972131239; Thu, 22 Apr 2010 14:35:31 -0700 (PDT) Message-ID: From: Peter Schuller To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: some arc_reclaim_needed stats 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, 22 Apr 2010 21:35:33 -0000 > But right now no one seems to think that there is anything useful about these > stats :-) Why do you say that? In any case, FWIW I think they are very useful. -- / Peter Schuller From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 21:48:52 2010 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 A3CA4106566B for ; Thu, 22 Apr 2010 21:48:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E2E8D8FC13 for ; Thu, 22 Apr 2010 21:48:51 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA15829; Fri, 23 Apr 2010 00:48:48 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O54GN-0008ab-MR; Fri, 23 Apr 2010 00:48:47 +0300 Message-ID: <4BD0C43F.7090107@icyb.net.ua> Date: Fri, 23 Apr 2010 00:48:47 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Peter Schuller References: <4BC86CF3.7060708@icyb.net.ua> <4BCEF7E4.6080606@dataix.net> <4BD0BC44.1040204@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: some arc_reclaim_needed stats 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, 22 Apr 2010 21:48:52 -0000 on 23/04/2010 00:35 Peter Schuller said the following: >> But right now no one seems to think that there is anything useful about these >> stats :-) > > Why do you say that? Because no one came up with interpretation of what they mean. > In any case, FWIW I think they are very useful. So, what sense do you make of those figures? :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 21:57:05 2010 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 A792F1065670 for ; Thu, 22 Apr 2010 21:57:05 +0000 (UTC) (envelope-from scode@scode.org) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 105608FC1D for ; Thu, 22 Apr 2010 21:57:04 +0000 (UTC) Received: by wwa36 with SMTP id 36so5829383wwa.13 for ; Thu, 22 Apr 2010 14:57:03 -0700 (PDT) MIME-Version: 1.0 Sender: scode@scode.org Received: by 10.216.50.11 with HTTP; Thu, 22 Apr 2010 14:57:03 -0700 (PDT) X-Originating-IP: [213.114.159.107] In-Reply-To: References: Date: Thu, 22 Apr 2010 23:57:03 +0200 X-Google-Sender-Auth: 9901e2c13da7e472 Received: by 10.216.90.73 with SMTP id d51mr3146247wef.31.1271973423712; Thu, 22 Apr 2010 14:57:03 -0700 (PDT) Message-ID: From: Peter Schuller To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 22 Apr 2010 21:57:05 -0000 > (I could pop it out of geom/zfs temporarily and hope the other disk > doesn't go. But as a matter of principle I don't want to go that > route...) Well, for now I went with that option anyway (zpool offline, gmirror remove, glabel stop, then disklabel, then zpool online etc). It would be interesting to hear though if there is a technical reason why the foot shooting flag does not apply to non-rank providers. If I'm missing something please enlighten me, but the particular use case of writing a boot strap on a slice is presumably not very unusual at all so I think it is something that ought to be possible to do. -- / Peter Schuller From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 22:04:54 2010 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 9C84E1065670; Thu, 22 Apr 2010 22:04:54 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 94EA38FC14; Thu, 22 Apr 2010 22:04:53 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA16158; Fri, 23 Apr 2010 01:04:52 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O54Vv-0008c9-NY; Fri, 23 Apr 2010 01:04:51 +0300 Message-ID: <4BD0C802.3000004@icyb.net.ua> Date: Fri, 23 Apr 2010 01:04:50 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org, freebsd-fs@FreeBSD.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: vdev_geom_io: parallelize ? 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, 22 Apr 2010 22:04:54 -0000 Just thinking out loud. Currently ZFS vdev_geom_io does something like: for (...) { ... g_io_request(...); biowait(...); ... } I/O is done in MAXPHYS chunks. If that was changed to first issuing all the requests and only after that waiting on them, could there be any performance benefit? Or cases of vdev_geom_io with size > MAXPHYS are too rare? Or something else? Thanks! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Apr 22 23:00:13 2010 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 2D83C106564A for ; Thu, 22 Apr 2010 23:00:13 +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 1B6A18FC0C for ; Thu, 22 Apr 2010 23:00: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 o3MN06f1019237 for ; Thu, 22 Apr 2010 23:00:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3MN06Ik019236; Thu, 22 Apr 2010 23:00:06 GMT (envelope-from gnats) Date: Thu, 22 Apr 2010 23:00:06 GMT Message-Id: <201004222300.o3MN06Ik019236@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 23:00:13 -0000 The following reply was made to PR kern/145339; it has been noted by GNATS. From: Andriy Gapon To: Alex Bakhtin Cc: bug-followup@freebsd.org, Pawel Jakub Dawidek Subject: Re: kern/145339: [zfs] deadlock after detaching block device from raidz pool Date: Fri, 23 Apr 2010 01:55:28 +0300 Can you try this patch? --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c @@ -603,6 +603,9 @@ vdev_geom_io_intr(struct bio *bp) zio = bp->bio_caller1; ctx = zio->io_vd->vdev_tsd; + if (ctx == NULL) + return; + if ((zio->io_error = bp->bio_error) == 0 && bp->bio_resid != 0) zio->io_error = EIO; -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 00:24:12 2010 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 B1785106564A for ; Fri, 23 Apr 2010 00:24:12 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 640D58FC08 for ; Fri, 23 Apr 2010 00:24:11 +0000 (UTC) Received: by qyk11 with SMTP id 11so10630824qyk.13 for ; Thu, 22 Apr 2010 17:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=qCJ+ZA1M7paIgVravmz61K1uW7TC+l5y44SIZH+LQoU=; b=x2VU55Vt7T92O869/i1ttpCAOIAYPH1iUGT8kyQsSxqpDsi8D91mF26ybKx8DAkgJP K7IcsulDBgtjM9csijH5cdqKlRCWJki2s0wukfB5Y3QyRXVMJs6CpZtiMpPzqk7yjceT FL3Dz1BRdtqbbxx9zx1MnlbY3skRuDIzQ+Isg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=qI+YfJ9qFEoVXroCBVC/8seFHcoiq9Vci+gZZYIwdCmYScRjc++VrqpQhDVlOyuFOP NvvasKR+BzGF1pKkh7LB19x5+MtJAzEMx4KZwUfa6Ot2BRpr92sp6kJ8gaOd0Q2yedwv eqjihoB/FWphJlW08biIWA9l5mrvB15RjEcz4= Received: by 10.224.88.40 with SMTP id y40mr3506956qal.383.1271982251478; Thu, 22 Apr 2010 17:24:11 -0700 (PDT) Received: from centel.dataix.local (c-71-205-129-194.hsd1.mi.comcast.net [71.205.129.194]) by mx.google.com with ESMTPS id 6sm1982089qwk.31.2010.04.22.17.24.07 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Apr 2010 17:24:10 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BD0E8A9.4040403@dataix.net> Date: Thu, 22 Apr 2010 20:24:09 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andriy Gapon References: <4BC86CF3.7060708@icyb.net.ua> <4BCEF7E4.6080606@dataix.net> <4BD0BC44.1040204@icyb.net.ua> In-Reply-To: <4BD0BC44.1040204@icyb.net.ua> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: some arc_reclaim_needed stats 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, 23 Apr 2010 00:24:12 -0000 On 04/22/2010 17:14, Andriy Gapon wrote: > on 21/04/2010 16:04 jhell said the following: >> If these are not tunable values and serve a good purpose as a stat to be >> added at some point, would they not be better in kstat.zfs.misc? rather >> than vfs.zfs so they can be collected with the rest of the stats via >> arc_summary.pl. > > Yes, I agree. > But right now no one seems to think that there is anything useful about these > stats :-) > >> Without seeing the thread "kstat.zfs.misc.arcstats.hash_collisions" I >> had updated the arc_summary.pl script yesterday to include these under a >> "ARC Misc" section in the output. Just a FYI in case it may be useful to >> you or others. > > BTW, it would be nice if hash table size (number of buckets) would be reported > too. But that's a kernel change, not arc_summary. > Something like what is in r59 and in the download section ? ARC Hash Breakdown: Elements Max: 129057 Elements Current: 99.24% 128070 Collisions: 251021 Chain Max: 21 Chains: 16326 ;) -- jhell From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 00:33:08 2010 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 A0C761065673 for ; Fri, 23 Apr 2010 00:33:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E33128FC16 for ; Fri, 23 Apr 2010 00:33:07 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id DAA18931; Fri, 23 Apr 2010 03:33:05 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O56pM-000AtT-JU; Fri, 23 Apr 2010 03:33:04 +0300 Message-ID: <4BD0EABF.6030100@icyb.net.ua> Date: Fri, 23 Apr 2010 03:33:03 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: jhell References: <4BC86CF3.7060708@icyb.net.ua> <4BCEF7E4.6080606@dataix.net> <4BD0BC44.1040204@icyb.net.ua> <4BD0E8A9.4040403@dataix.net> In-Reply-To: <4BD0E8A9.4040403@dataix.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: some arc_reclaim_needed stats 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, 23 Apr 2010 00:33:08 -0000 on 23/04/2010 03:24 jhell said the following: > On 04/22/2010 17:14, Andriy Gapon wrote: >> on 21/04/2010 16:04 jhell said the following: >>> If these are not tunable values and serve a good purpose as a stat to be >>> added at some point, would they not be better in kstat.zfs.misc? rather >>> than vfs.zfs so they can be collected with the rest of the stats via >>> arc_summary.pl. >> Yes, I agree. >> But right now no one seems to think that there is anything useful about these >> stats :-) >> >>> Without seeing the thread "kstat.zfs.misc.arcstats.hash_collisions" I >>> had updated the arc_summary.pl script yesterday to include these under a >>> "ARC Misc" section in the output. Just a FYI in case it may be useful to >>> you or others. >> BTW, it would be nice if hash table size (number of buckets) would be reported >> too. But that's a kernel change, not arc_summary. >> > > Something like what is in r59 and in the download section ? > > ARC Hash Breakdown: > Elements Max: 129057 > Elements Current: 99.24% 128070 > Collisions: 251021 > Chain Max: 21 > Chains: 16326 No, I mean number of the buckets (not elements) in the hash table. http://en.wikipedia.org/wiki/Hash_table :-) -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 01:09:02 2010 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 1ECE7106566B for ; Fri, 23 Apr 2010 01:09:02 +0000 (UTC) (envelope-from davidn04@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id C4E828FC12 for ; Fri, 23 Apr 2010 01:09:01 +0000 (UTC) Received: by mail-qy0-f181.google.com with SMTP id 11so10684260qyk.13 for ; Thu, 22 Apr 2010 18:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=guhybTC85awMpoZNQMf5Lm5si4fcS0n7FAS6CH7/2Ro=; b=v+EUdpmu9eMP2gZSJsmRx4eoZv6JK0tif1Nd06mYMM1SngcLpcBL7ubpEuySgXKVh5 XW8IAr1oriiGG9TjIjbz87RG7PQzvkUQxlknUmTQBqGTBhXY1/PnmdgegZGNyNywkQjm 10/Evo/GRd6me30pwsf4gnvKVSt/PpJfPF0wM= 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=bnp9h+wZzagnXicDQ//s238Efqz8OptLvJCWCLgxroxJ0x9CRAKJX7XCF/weNPh9Tz j8+aLD1iUunGfe5XdjLnQK3XwvuR/r7YFqCnsfdUu3Plvqu0m4d84PlNxfCALfcXMpQ6 ej5qUVY/4QAfnCws7TDAKmzBF84GHElFfFjGg= MIME-Version: 1.0 Received: by 10.229.87.142 with HTTP; Thu, 22 Apr 2010 18:09:01 -0700 (PDT) In-Reply-To: References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> <20100421095054.GA28619@duncan.reilly.home> Date: Fri, 23 Apr 2010 11:09:01 +1000 Received: by 10.229.190.209 with SMTP id dj17mr6929302qcb.52.1271984941411; Thu, 22 Apr 2010 18:09:01 -0700 (PDT) Message-ID: From: David N To: Andrew Reilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 23 Apr 2010 01:09:02 -0000 On 21 April 2010 21:47, David N wrote: > On 21 April 2010 19:50, Andrew Reilly wrote: >> Hi David, >> >> On Wed, Apr 21, 2010 at 07:16:08PM +1000, David N wrote: >>> Can you show me a print out of >>> gjournal list >> >> here: >> >> >> Geom name: gjournal 827322917 >> ID: 827322917 >> Providers: >> 1. Name: mirror/gm0e.journal >> =A0 Mediasize: 981949479936 (915G) >> =A0 Sectorsize: 512 >> =A0 Mode: r1w1e1 >> Consumers: >> 1. Name: mirror/gm0e >> =A0 Mediasize: 983023222272 (916G) >> =A0 Sectorsize: 512 >> =A0 Mode: r1w1e1 >> =A0 Jend: 983023221760 >> =A0 Jstart: 981949479936 >> =A0 Role: Data,Journal >> >> Geom name: gjournal 1843456033 >> ID: 1843456033 >> Providers: >> 1. Name: ad8s1a.journal >> =A0 Mediasize: 1499228127232 (1.4T) >> =A0 Sectorsize: 512 >> =A0 Mode: r1w1e1 >> Consumers: >> 1. Name: ad8s1a >> =A0 Mediasize: 1500301869568 (1.4T) >> =A0 Sectorsize: 512 >> =A0 Mode: r1w1e1 >> =A0 Jend: 1500301869056 >> =A0 Jstart: 1499228127232 >> =A0 Role: Data,Journal >> >> Geom name: gjournal 3015273731 >> ID: 3015273731 >> Providers: >> 1. Name: ad10s1.journal >> =A0 Mediasize: 749081051136 (698G) >> =A0 Sectorsize: 512 >> =A0 Mode: r1w1e1 >> Consumers: >> 1. Name: ad10s1 >> =A0 Mediasize: 750154793472 (699G) >> =A0 Sectorsize: 512 >> =A0 Mode: r1w1e1 >> =A0 Jend: 750154792960 >> =A0 Jstart: 749081051136 >> =A0 Role: Data,Journal >> >> >>> and >>> bsdlabel /dev/mirror/gm0e.journal >> >> duncan [201]$ bsdlabel mirror/gm0e.journal >> bsdlabel: /dev/mirror/gm0e.journal: no valid label found >> >>> And any other .journal you have >> >> duncan [202]$ bsdlabel ad8s1a.journal >> bsdlabel: /dev/ad8s1a.journal: no valid label found >> duncan [203]$ bsdlabel ad10s1.journal >> # /dev/ad10s1.journal: >> 8 partitions: >> # =A0 =A0 =A0 =A0size =A0 offset =A0 =A0fstype =A0 [fsize bsize bps/cpg] >> =A0a: 1465146065 =A0 =A0 =A0 16 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 0 >> =A0c: 1465146081 =A0 =A0 =A0 =A00 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0= 0 =A0 =A0 =A0 =A0 # "raw" part, don't edit >> partition a: partition extends past end of unit >> partition c: partition extends past end of unit >> bsdlabel: partition c doesn't cover the whole unit! >> bsdlabel: An incorrect partition c may cause problems for standard syste= m utilities >> >> Hmm. =A0That's a bit surprising. =A0I'm fairly certain that I didn't >> label ad10s1.journal, but that disk has been used for other >> things before, and the partition label is the the same (but >> without the warnings): >> >> duncan [204]$ bsdlabel ad10s1 >> # /dev/ad10s1: >> 8 partitions: >> # =A0 =A0 =A0 =A0size =A0 offset =A0 =A0fstype =A0 [fsize bsize bps/cpg] >> =A0a: 1465146065 =A0 =A0 =A0 16 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 0 >> =A0c: 1465146081 =A0 =A0 =A0 =A00 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0= 0 =A0 =A0 =A0 =A0 # "raw" part, don't edit >> >> I guess I should have nuked the starting sectors a bit more >> thoroughly? >> >> That isn't the disk that's giving me panics though. >> >>> Just want to double check something. >> >> Hope that helps! >> >> Cheers, >> >> -- >> Andrew >> >> > > Sorry, i forgot the gm0e and ad8s1a is a label. > can you show me the bsdlabel for the mirror/gm0 and ad8s1 > > Also there is a overflow with the ad10s1 and journal > > Geom name: gjournal 3015273731 > ID: 3015273731 > Providers: > 1. Name: ad10s1.journal > =A0Mediasize: 749081051136 (698G) > =A0Sectorsize: 512 > =A0Mode: r1w1e1 > Consumers: > 1. Name: ad10s1 > =A0Mediasize: 750154793472 (699G) > =A0Sectorsize: 512 > =A0Mode: r1w1e1 > =A0Jend: 750154792960 > =A0Jstart: 749081051136 > =A0Role: Data,Journal > > duncan [204]$ bsdlabel ad10s1 > # /dev/ad10s1: > 8 partitions: > # =A0 =A0 =A0 =A0size =A0 offset =A0 =A0fstype =A0 [fsize bsize bps/cpg] > =A0a: 1465146065 =A0 =A0 =A0 16 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 0 > =A0c: 1465146081 =A0 =A0 =A0 =A00 =A0 =A0unused =A0 =A0 =A0 =A00 =A0 =A0 = 0 =A0 =A0 =A0 =A0 # "raw" part, > don't edit > partition a: partition extends past end of unit > partition c: partition extends past end of unit > bsdlabel: partition c doesn't cover the whole unit! > bsdlabel: An incorrect partition c may cause problems for standard > system utilities > > When i first started, it kept complaining. For slices, you have the > ad10, put the s1 slice in, then you gjournal that, bsdlabel the > .journal. Then change the label to the mediasize of the journal/512. > > So in your case your bsdlabel should be 749081051136 / 512 =3D > 1463048928 with offset of 0. > c: 1465146081 - (what is expected)1463048928 =3D 2097153*512 =3D > 1073742336 (which is roughly 1GB, your journal size) > Your c label is over by about 1GB =A0which means the fs is writing over > the journal part sometimes and the journal writing over the data > sometimes, which would lead to the journal overflow and journal/data > corruption. > > I hope i haven't confused you. I started to gjournal the slices as > gjournalling the bsdlabels you needed to decrease your bsdlabel by 1 > (thats where the GEOM data was stored) and gave me too many headaches. > > If you gjournal the slices, then bsdlabel them, you just change the c > label to (.journal media size)/512 offset 0, and it all works. > > Regards > David N > Could you also post a df (without the -h), if you haven't already solved the problem. Cheers David N From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 01:10:37 2010 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 77C601065673 for ; Fri, 23 Apr 2010 01:10:37 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 291548FC1C for ; Fri, 23 Apr 2010 01:10:36 +0000 (UTC) Received: by qyk11 with SMTP id 11so10686772qyk.13 for ; Thu, 22 Apr 2010 18:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=UhjvMp21IYmX4oQ9fHYz0hNcQ1l5Rv2o43SFNcMqMy4=; b=Q1Bk8RQOEpVIsPQR+cwU2GeRfvmGGqQjX1gLiDgzMACIfT43UwFNMtqWXbANDKLjVm 0z+8t2SJI+AIsn1F+K1wvMMYPJqXBfNcWelOzdKfYVt3LSwM8HbX8FmYfJGU13LGrwQX H5G8C3fHcVKPZumGMj7sWPu4un+uB/zg/FpY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=cDHR93Pn/YF69QT3K5KQChZi7pD4WUo39wuHMtZy/ywogjKbs6Lylmm2422lkLT6iF H/M+IoDBe1ZCi2KjqDGM3hmSyYqkFB7pKANvxoUVH/A/w02elk8cDusaZ4tftCoFHncP UrJ6KSwBtt4nxgd1vUdE0RnUyAm3KOKc69soM= Received: by 10.224.26.223 with SMTP id f31mr3553714qac.56.1271985036160; Thu, 22 Apr 2010 18:10:36 -0700 (PDT) Received: from centel.dataix.local (c-71-205-129-194.hsd1.mi.comcast.net [71.205.129.194]) by mx.google.com with ESMTPS id 6sm1468787qwd.23.2010.04.22.18.10.35 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Apr 2010 18:10:35 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BD0F38A.9040107@dataix.net> Date: Thu, 22 Apr 2010 21:10:34 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andriy Gapon References: <4BC86CF3.7060708@icyb.net.ua> <4BCEF7E4.6080606@dataix.net> <4BD0BC44.1040204@icyb.net.ua> <4BD0E8A9.4040403@dataix.net> <4BD0EABF.6030100@icyb.net.ua> In-Reply-To: <4BD0EABF.6030100@icyb.net.ua> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: some arc_reclaim_needed stats 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, 23 Apr 2010 01:10:37 -0000 On 04/22/2010 20:33, Andriy Gapon wrote: > on 23/04/2010 03:24 jhell said the following: >> On 04/22/2010 17:14, Andriy Gapon wrote: >>> on 21/04/2010 16:04 jhell said the following: >>>> If these are not tunable values and serve a good purpose as a stat to be >>>> added at some point, would they not be better in kstat.zfs.misc? rather >>>> than vfs.zfs so they can be collected with the rest of the stats via >>>> arc_summary.pl. >>> Yes, I agree. >>> But right now no one seems to think that there is anything useful about these >>> stats :-) >>> >>>> Without seeing the thread "kstat.zfs.misc.arcstats.hash_collisions" I >>>> had updated the arc_summary.pl script yesterday to include these under a >>>> "ARC Misc" section in the output. Just a FYI in case it may be useful to >>>> you or others. >>> BTW, it would be nice if hash table size (number of buckets) would be reported >>> too. But that's a kernel change, not arc_summary. >>> >> >> Something like what is in r59 and in the download section ? >> >> ARC Hash Breakdown: >> Elements Max: 129057 >> Elements Current: 99.24% 128070 >> Collisions: 251021 >> Chain Max: 21 >> Chains: 16326 > > No, I mean number of the buckets (not elements) in the hash table. > http://en.wikipedia.org/wiki/Hash_table > :-) > Lol I read your reply one way and took it completely different in thinking that you wanted the ARC Hash stats and was not paying to close attention to the specific need of "hash buckets". My bad... Regards, -- jhell From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 02:41:24 2010 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 E6FFC1065672 for ; Fri, 23 Apr 2010 02:41:24 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-pz0-f172.google.com (mail-pz0-f172.google.com [209.85.222.172]) by mx1.freebsd.org (Postfix) with ESMTP id BCEF48FC16 for ; Fri, 23 Apr 2010 02:41:24 +0000 (UTC) Received: by mail-pz0-f172.google.com with SMTP id 2so6101283pzk.27 for ; Thu, 22 Apr 2010 19:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=bhD2rguxRxLY3WKSrHvnbJdABmuzNL8a8u2dIeXHFUU=; b=uROgnaO5s0tHMVQlk+O0o51H10UO0f1ub1zldz6llU+5GEVD2D+mbnHgtzZgJHST2M PAaxYm57DX0dh3W2vmw/KzmOYtU9rPMvyJUMexh3z5r32xuJwX8OA1UTDyJ3dhVK1H6+ KBRyrN0z/ejhufj6ZV+0iuxFJ9VCW4xvDJNNQ= 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=gZhNVxCgwbMOpR1X7QzYbaa+WnBoklRxyVswdmGJ4DqT9WwLv5dBok2yVEcv+7NrH1 H4oOk7PXU4XE45tLc+FxS5gsk5jOS72l4bv8tL5GzMU27TmppFdPazQRgWMJ8rF8LN0J QzjH+5ct575WW3/wLyiiZGB4qYD4voft8PeTY= MIME-Version: 1.0 Received: by 10.142.221.6 with HTTP; Thu, 22 Apr 2010 19:13:32 -0700 (PDT) In-Reply-To: <201004221758.o3MHwTb2006547@higson.cam.lispworks.com> References: <201004221441.PAA07296@wratting.cam.lispworks.com> <4BD0670A.8070205@xpam.de> <201004221758.o3MHwTb2006547@higson.cam.lispworks.com> Date: Thu, 22 Apr 2010 21:13:32 -0500 Received: by 10.142.208.12 with SMTP id f12mr443781wfg.226.1271988812476; Thu, 22 Apr 2010 19:13:32 -0700 (PDT) Message-ID: From: Chris Ruiz To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: zfs: unexpected resilver of old disk when attaching a new mirror disk 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, 23 Apr 2010 02:41:25 -0000 On Thu, Apr 22, 2010 at 12:58 PM, Martin Simmons wrote: >>>>>> On Thu, 22 Apr 2010 17:11:06 +0200, Adam Nowacki said: >> >> My best guess is metadata updates to refer to the 2nd disk. I've seen >> same behavior when replacing a bad disk in 10 disk raidz2 pool. No data >> was affected. > > I would expect all new writes to automatically go to all disks though, so they > wouldn't be counted as resilvering. > > __Martin I don't know the reason why this happens but I do know that it's normal and that your data is ok. -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 03:03:46 2010 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 7B1F61065674 for ; Fri, 23 Apr 2010 03:03:46 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id 0237F8FC14 for ; Fri, 23 Apr 2010 03:03:45 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([124.188.161.100]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20100423030344.XQTJ12504.nskntmtas01p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Fri, 23 Apr 2010 03:03:44 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20100423030343.SXQA1978.nskntotgx03p.mx.bigpond.com@duncan.reilly.home>; Fri, 23 Apr 2010 03:03:43 +0000 Date: Fri, 23 Apr 2010 13:03:43 +1000 From: Andrew Reilly To: David N Message-ID: <20100423030343.GA1347@duncan.reilly.home> References: <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> <20100421095054.GA28619@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Fri, 23 Apr 2010 03:03:43 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4BD10E10.003C,ss=1,fgs=0 X-SIH-MSG-ID: qRAxE9P8TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rVMfpRsM6kxDxPJhqGNGEjaajgTY3Rs9mK Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 23 Apr 2010 03:03:46 -0000 Hi David, On Fri, Apr 23, 2010 at 11:09:01AM +1000, David N wrote: > Could you also post a df (without the -h), if you haven't already > solved the problem. Sorry, no progress has been made by me on this issue ran out of attention-rons. Filesystem 512-blocks Used Avail Capacity Mounted on /dev/mirror/gm0a 4052056 1073884 2654008 29% / devfs 2 2 0 100% /dev /dev/mirror/gm0d 20308312 527856 18155792 3% /var /dev/mirror/gm0e.journal 1857509436 579437824 1129470860 34% /usr /dev/ad10s1.journal 1417002884 444064960 859577696 34% /nb procfs 8 8 0 100% /proc /dev/md0 126428 160 116156 0% /tmp /dev/ad8s1a.journal 2836028812 1350955708 1258190800 52% /mnt Hopefully I'll have a chance to look at this some more over the weekend. Might give SUJ a spin, as an alternative, too. Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 03:23:29 2010 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 E04C2106566C for ; Fri, 23 Apr 2010 03:23:28 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id 67A9A8FC08 for ; Fri, 23 Apr 2010 03:23:28 +0000 (UTC) Received: from nskntotgx02p.mx.bigpond.com ([124.188.161.100]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20100423032327.ZJFP12504.nskntmtas01p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com>; Fri, 23 Apr 2010 03:23:27 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20100423032326.ZJEH2010.nskntotgx02p.mx.bigpond.com@duncan.reilly.home>; Fri, 23 Apr 2010 03:23:26 +0000 Date: Fri, 23 Apr 2010 13:23:26 +1000 From: Andrew Reilly To: David N Message-ID: <20100423032326.GB1347@duncan.reilly.home> References: <20100418235428.GC4620@duncan.reilly.home> <20100420234447.GB1737@garage.freebsd.pl> <20100421011834.GA24928@duncan.reilly.home> <20100421024803.GA25701@duncan.reilly.home> <20100421085228.GA27892@duncan.reilly.home> <20100421095054.GA28619@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nskntotgx02p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Fri, 23 Apr 2010 03:23:26 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.4BD112AE.0171,ss=1,fgs=0 X-SIH-MSG-ID: qRs3FtHuXAD+xDJw0jPvNAJ+xA/u8yI74J0WRdJsoQQZSkfduMHeU7zhKrMwgcz21j1cNhmPPGIqYav0X4/QsuM= Cc: freebsd-fs@freebsd.org Subject: Re: gjournal: what is it good for? 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, 23 Apr 2010 03:23:29 -0000 On Wed, Apr 21, 2010 at 09:47:32PM +1000, David N wrote: > Sorry, i forgot the gm0e and ad8s1a is a label. > can you show me the bsdlabel for the mirror/gm0 and ad8s1 bsdlabel: unable to get correct path for mirror/gm0: No such file or directory Sorry for the confusion: gm0e is a gmirror label that I made up, to remind me that the mirror components are the "e" partition of the underlying drives: $ gmirror status Name Status Components mirror/gm0a COMPLETE ad4s1a ad6s1a mirror/gm0d COMPLETE ad4s1d ad6s1d mirror/gm0e COMPLETE ad4s1e ad6s1e # /dev/ad8s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2930277089 16 unused 0 0 c: 2930277105 0 unused 0 0 # "raw" part, don't edit > Also there is a overflow with the ad10s1 and journal Hmm. I'm not sure about that, but it does look as though I should have used ad10s1a as the provider, rather than just ad10s1. I bsdlabel'd ad10s1 (which is where the a and c partitions are correct), but then I went and gjournal labelled ad10s1, rather than ad10s1a. I'm pretty sure that the label that was displayed for ad10s1.journal is just something that was poking through, since the journal metadata is at the end of the space. > When i first started, it kept complaining. For slices, you have the > ad10, put the s1 slice in, then you gjournal that, bsdlabel the > .journal. Then change the label to the mediasize of the journal/512. > > So in your case your bsdlabel should be 749081051136 / 512 = > 1463048928 with offset of 0. > c: 1465146081 - (what is expected)1463048928 = 2097153*512 = > 1073742336 (which is roughly 1GB, your journal size) > Your c label is over by about 1GB which means the fs is writing over > the journal part sometimes and the journal writing over the data > sometimes, which would lead to the journal overflow and journal/data > corruption. I'll have another go at spinning that all around this weekend. It isn't clear to me when or why the file system pays attention to a bsdlabel. Most of my file systems are on GEOM providers that are *not* bsdlabelled, and that doesn't seem to worry them. In this case, the c partition that seems to overhang the journal space is *not* related to or used by the file system, or at least shouldn't be. > I hope i haven't confused you. I started to gjournal the slices as > gjournalling the bsdlabels you needed to decrease your bsdlabel by 1 > (thats where the GEOM data was stored) and gave me too many headaches. > > If you gjournal the slices, then bsdlabel them, you just change the c > label to (.journal media size)/512 offset 0, and it all works. Reckon I'm going to be switching over to SUJ as soon as possible: hopefully it'll have a different set of gotchas. Thanks for the help! Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 06:08:56 2010 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 9B606106566C; Fri, 23 Apr 2010 06:08:56 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 33CCE8FC08; Fri, 23 Apr 2010 06:08:55 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8BB7445E8E; Fri, 23 Apr 2010 08:08:54 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 554384569A; Fri, 23 Apr 2010 08:08:49 +0200 (CEST) Date: Fri, 23 Apr 2010 08:08:50 +0200 From: Pawel Jakub Dawidek To: Andriy Gapon Message-ID: <20100423060850.GB1670@garage.freebsd.pl> References: <4BD0C802.3000004@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <4BD0C802.3000004@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: vdev_geom_io: parallelize ? 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, 23 Apr 2010 06:08:56 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2010 at 01:04:50AM +0300, Andriy Gapon wrote: >=20 > Just thinking out loud. >=20 > Currently ZFS vdev_geom_io does something like: > for (...) { > ... > g_io_request(...); > biowait(...); > ... > } > I/O is done in MAXPHYS chunks. >=20 > If that was changed to first issuing all the requests and only after that > waiting on them, could there be any performance benefit? > Or cases of vdev_geom_io with size > MAXPHYS are too rare? > Or something else? The vdev_geom_io() function is there only to read ZFS labels, it is not used during regular I/O. Regular I/O requests are handled asynchronously by the vdev_geom_io_start() function. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvROXIACgkQForvXbEpPzSM9wCcDPLqokCtvb9D/QzxkGAOX3oL t90An3ssb9u19Zgw/x32k0xE5P5QLnHF =LTp5 -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 06:15:26 2010 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 C9480106566C for ; Fri, 23 Apr 2010 06:15:26 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 124248FC08 for ; Fri, 23 Apr 2010 06:15:25 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id ADC5A45C99; Fri, 23 Apr 2010 08:15:24 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 59A81456B1; Fri, 23 Apr 2010 08:15:19 +0200 (CEST) Date: Fri, 23 Apr 2010 08:15:21 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100423061521.GC1670@garage.freebsd.pl> References: <20100416065126.GG1705@garage.freebsd.pl> <4BCD3979.8050107@soupacific.com> <4BCD5AD7.8070502@soupacific.com> <4BCFA4C2.6000109@soupacific.com> <4BCFB1C5.5000908@soupacific.com> <4BD01800.9040901@soupacific.com> <4BD0438B.5080308@soupacific.com> <4BD0E432.1000108@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZwgA9U+XZDXt4+m+" Content-Disposition: inline In-Reply-To: <4BD0E432.1000108@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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, 23 Apr 2010 06:15:26 -0000 --ZwgA9U+XZDXt4+m+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2010 at 09:05:06AM +0900, hiroshi@soupacific.com wrote: > Hi ! >=20 > >This is expected. GEOM provider will be available only on primary node, > >because this is where it should be accessed. >=20 > Sorry to confuse you. > What I said is situation of; >=20 > nodea and nodeb, nodeb was downed (say system is failured) . > and reboot nodea. >=20 > nodea is primary condition but not able to access hast/test. >=20 > Is this your expectation ? This is not expected, but remember that hastd daemon is not responsible for configuring its role automatically. You have to use ucarp, carp or similar HA software to negotiate role and use 'hastctl role primary/secondary' command to start hast. Could you provide output of 'hastctl status' command for both your nodes? > p.s. I removed dnsbl.sorbs.net blocker. Thanks. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ZwgA9U+XZDXt4+m+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvROvgACgkQForvXbEpPzQAEgCZAeIRykQxRIf4+5ng0lzKOB+b eeAAoJzNR3mV4xP4nyfjxElJOEWvbLJn =Rf6/ -----END PGP SIGNATURE----- --ZwgA9U+XZDXt4+m+-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 06:29:56 2010 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 34E871065675 for ; Fri, 23 Apr 2010 06:29:56 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8FCD28FC16 for ; Fri, 23 Apr 2010 06:29:55 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0A6C545C99; Fri, 23 Apr 2010 08:29:54 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3B4BE45683; Fri, 23 Apr 2010 08:29:48 +0200 (CEST) Date: Fri, 23 Apr 2010 08:29:50 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100423062950.GD1670@garage.freebsd.pl> References: <86r5m9dvqf.fsf@zhuzha.ua1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YToU2i3Vx8H2dn7O" Content-Disposition: inline In-Reply-To: <86r5m9dvqf.fsf@zhuzha.ua1> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 23 Apr 2010 06:29:56 -0000 --YToU2i3Vx8H2dn7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 21, 2010 at 12:02:16PM +0300, Mikolaj Golub wrote: > Restoring network after this changes nothing. Primary gets stuck. No mess= ages > in the log and "dirty" in status output does not change: >=20 > [root@hasta ~]# hastctl status > storage: > role: primary > provname: storage > localpath: /dev/ad4 > extentsize: 2097152 > keepdirty: 64 > remoteaddr: 172.20.66.202 > replication: memsync > status: complete > dirty: 2097152 bytes >=20 > On the secondary we have all this time: >=20 > tcp4 0 0 172.20.66.202.8457 172.20.66.201.57596 ESTABLI= SHED > tcp4 0 0 172.20.66.202.8457 172.20.66.201.41841 ESTABLI= SHED >=20 > The last messages in log: >=20 > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0)= Request received from the kernel: READ(13565952, 65536). > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0)= Moving request to the send queue. > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: Taking free = request. > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80)= Got free request. > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80)= Waiting for request from the kernel. > Apr 21 10:50:21 hasta hastd: [storage] (primary) local_send: (0x28411bc0)= Got request. > Apr 21 10:50:21 hasta hastd: [storage] (primary) local_send: (0x28411bc0)= Moving request to the done queue. > Apr 21 10:50:21 hasta hastd: [storage] (primary) local_send: Taking reque= st. > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_send: (0x28411bc0)= Got request. > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_send: (0x28411bc0)= Moving request to the free queue. > Apr 21 10:50:21 hasta hastd: [storage] (primary) ggate_send: Taking reque= st. > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80)= Request received from the kernel: READ(1812529152, 65536). > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80)= Moving request to the send queue. > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: Taking free = request. > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b00)= Got free request. > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_recv: (0x28411b00)= Waiting for request from the kernel. > Apr 21 10:51:00 hasta hastd: [storage] (primary) local_send: (0x28411b80)= Got request. > Apr 21 10:51:00 hasta hastd: [storage] (primary) local_send: (0x28411b80)= Moving request to the done queue. > Apr 21 10:51:00 hasta hastd: [storage] (primary) local_send: Taking reque= st. > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_send: (0x28411b80)= Got request. > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_send: (0x28411b80)= Moving request to the free queue. > Apr 21 10:51:00 hasta hastd: [storage] (primary) ggate_send: Taking reque= st. >=20 > The backtrace of gotten stuck hastd is in the attach. >=20 > I interpret this in the following way. Although the network is down > hast_proto_send() in remote_send_thread() returns success (sent data are > stored in the kernel buffer). Then kernel tries to send data and eventual= ly > fails after timeout and close the socket. hastd is not aware about this, > remote_send_thread() is blocked in "Taking request" at this time, sync th= read > is waiting for status from the secondary about sent data but secondary do= es > not send it because it did not receive any data. "Taking request" only means that HAST is waiting for a request. In case of ggate_send thread it means it is waiting for I/O request from the kernel. It stops here, because there is no new request. > Restarting hastd on the secondary usually helps. A workaround is to set > net.inet.tcp.keepidle to some small value (e.g. 300 sec) on the > secondary. Then the secondary will notice much earlier that the peer has > closed the connection and will restart the worker itself: >=20 > Apr 21 11:52:21 hastb hastd: [storage] (secondary) Unable to receive requ= est header: Connection reset by peer. > Apr 21 11:52:21 hastb hastd: [storage] (secondary) Worker process (pid=3D= 1398) exited ungracefully: status=3D19200. What you are observing here is because currently there is no keep-alive mechanism in hastd, so if there are no I/O requests, primary won't notice that secondary is down until next I/O request arrives. I don't consider it critical, but confusing. Note that when secondary goes down and there are no I/O requests to primary, there will be nothing to synchronize, so fast reconnect isn't crucial in this case. We need one I/O request coming to primary to discover that secondary is down and start reconnect loop. Could you confirm this is what you are observing? If not, what FreeBSD version do you use? If it is HEAD, do you have r205738? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --YToU2i3Vx8H2dn7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvRPl0ACgkQForvXbEpPzQ2BwCgz94Ij8Xsz+SdrF+OvT3IOfev Q8IAoIIFvxvBuCU6/mPquHRcuaiQgChh =Ab6v -----END PGP SIGNATURE----- --YToU2i3Vx8H2dn7O-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 06:42:56 2010 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 8D2CA106564A; Fri, 23 Apr 2010 06:42:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 67F588FC1E; Fri, 23 Apr 2010 06:42:55 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA23663; Fri, 23 Apr 2010 09:42:54 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O5CbF-000BL2-Nu; Fri, 23 Apr 2010 09:42:53 +0300 Message-ID: <4BD1416D.30207@icyb.net.ua> Date: Fri, 23 Apr 2010 09:42:53 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4BD0C802.3000004@icyb.net.ua> <20100423060850.GB1670@garage.freebsd.pl> In-Reply-To: <20100423060850.GB1670@garage.freebsd.pl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: vdev_geom_io: parallelize ? 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, 23 Apr 2010 06:42:56 -0000 on 23/04/2010 09:08 Pawel Jakub Dawidek said the following: > On Fri, Apr 23, 2010 at 01:04:50AM +0300, Andriy Gapon wrote: >> Just thinking out loud. >> >> Currently ZFS vdev_geom_io does something like: >> for (...) { >> ... >> g_io_request(...); >> biowait(...); >> ... >> } >> I/O is done in MAXPHYS chunks. >> >> If that was changed to first issuing all the requests and only after that >> waiting on them, could there be any performance benefit? >> Or cases of vdev_geom_io with size > MAXPHYS are too rare? >> Or something else? > > The vdev_geom_io() function is there only to read ZFS labels, it is not > used during regular I/O. Regular I/O requests are handled asynchronously > by the vdev_geom_io_start() function. Oops. Thanks! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 08:36:05 2010 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 D4E7C1065670 for ; Fri, 23 Apr 2010 08:36:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 8329C8FC1B for ; Fri, 23 Apr 2010 08:36:04 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id 8wY91e0010vyq2s5Awc5M2; Fri, 23 Apr 2010 08:36:05 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.westchester.pa.mail.comcast.net with comcast id 8wc31e0063S48mS3Rwc3Y4; Fri, 23 Apr 2010 08:36:05 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 356589B42D; Fri, 23 Apr 2010 01:23:45 -0700 (PDT) Date: Fri, 23 Apr 2010 01:23:45 -0700 From: Jeremy Chadwick To: Peter Schuller Message-ID: <20100423082345.GA27379@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 08:36:05 -0000 On Thu, Apr 22, 2010 at 10:55:29PM +0200, Peter Schuller wrote: > open() in O_RDWR fails on the device in question (which is "used" by > glabel, indirectly by gmirror and zfs). > > This is on an 8.0 userland and 8-STABLE kernel. This is a bit stupid I > know (nevermind why), but given that a plain open() syscall is failing > I highly doubt that it has anything to do with the userland being out > of synch. I cannot imagine GEOM changing like that in between 8.0 and > 8-STABLE before the 8.1 release (correct me if this is a poor > assumption). > > Observe: > > % whoami > root > % sysctl -w kern.geom.debugflags=16 > kern.geom.debugflags: 16 -> 16 > % sysctl kern.geom.debugflags > kern.geom.debugflags: 16 > % ktrace disklabel -B /dev/ad9s1 > disklabel: Class not found You'd have seen this problem on 8.0-RELEASE as well. I've been bitching about it since trying out 8.0-RC1. The "Class not found" errors have existed for way too long, and are confusing people left and right. Supposedly we're supposed to use gpart(8) now, but I haven't figured out how to use it in the same way as bsdlabel. -- | 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 Fri Apr 23 08:59:14 2010 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 6BAA01065673 for ; Fri, 23 Apr 2010 08:59:14 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [77.88.46.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1511B8FC14 for ; Fri, 23 Apr 2010 08:59:13 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward5.mail.yandex.net (Yandex) with ESMTP id 3205814D0E6F; Fri, 23 Apr 2010 12:59:12 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1272013152; bh=iHOx2OIQ3C8E4ps6MVZmlu1g0QMfWI7+Orltk6iALbY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ry0+T3WeN9kSxdaN3UIvW2BW3YdcBppa5qvg0w5Q89+re239+kXhlSPeE6gt7++p1 d17OHM5MaRGdi5YK86OO7exINUkClgG1PHs+9++9AHCBmo9EV5XPew1mySe+meFMY0 lK4nTE0JKfsnuIUsu4EB0oZdWNZjjUeA7peg6JNo= Received: from [127.0.0.1] (unknown [188.128.19.1]) by smtp3.mail.yandex.net (Yandex) with ESMTPSA id D83DF278137; Fri, 23 Apr 2010 12:59:11 +0400 (MSD) Message-ID: <4BD1615E.9010909@yandex.ru> Date: Fri, 23 Apr 2010 12:59:10 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Jeremy Chadwick References: <20100423082345.GA27379@icarus.home.lan> In-Reply-To: <20100423082345.GA27379@icarus.home.lan> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1272013152 X-Yandex-Spam: 1 X-Yandex-Front: smtp3.mail.yandex.net Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 08:59:14 -0000 On 23.04.2010 12:23, Jeremy Chadwick wrote: > Supposedly we're supposed to use gpart(8) now, but I haven't figured out > how to use it in the same way as bsdlabel. It's easy. # gpart create -s mbr md0 md0 created # gpart add -t freebsd md0 md0s1 added # gpart create -s bsd md0s1 md0s1 created # gpart add -t freebsd-ufs -s 50m md0s1 md0s1a added # gpart add -t freebsd-swap md0s1 md0s1b added # gpart bootcode -b /boot/boot md0s1 md0s1 has bootcode # gpart bootcode -b /boot/mbr md0 md0 has bootcode # gpart set -a active -i 1 md0 md0s1 has active set -- WBR, Andrey V. Elsukov From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 09:02:29 2010 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 3CF90106564A for ; Fri, 23 Apr 2010 09:02:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 22CAA8FC1D for ; Fri, 23 Apr 2010 09:02:28 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 8wwo1e0020mlR8UAEx2Vdr; Fri, 23 Apr 2010 09:02:29 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.emeryville.ca.mail.comcast.net with comcast id 8x2U1e0083S48mS8Xx2UJY; Fri, 23 Apr 2010 09:02:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6BC169B419; Fri, 23 Apr 2010 02:02:27 -0700 (PDT) Date: Fri, 23 Apr 2010 02:02:27 -0700 From: Jeremy Chadwick To: "Andrey V. Elsukov" Message-ID: <20100423090227.GA29149@icarus.home.lan> References: <20100423082345.GA27379@icarus.home.lan> <4BD1615E.9010909@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD1615E.9010909@yandex.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 09:02:29 -0000 On Fri, Apr 23, 2010 at 12:59:10PM +0400, Andrey V. Elsukov wrote: > On 23.04.2010 12:23, Jeremy Chadwick wrote: > >Supposedly we're supposed to use gpart(8) now, but I haven't figured out > >how to use it in the same way as bsdlabel. > > It's easy. > > # gpart create -s mbr md0 > md0 created > # gpart add -t freebsd md0 > md0s1 added > # gpart create -s bsd md0s1 > md0s1 created > # gpart add -t freebsd-ufs -s 50m md0s1 > md0s1a added > # gpart add -t freebsd-swap md0s1 > md0s1b added > # gpart bootcode -b /boot/boot md0s1 > md0s1 has bootcode > # gpart bootcode -b /boot/mbr md0 > md0 has bootcode > # gpart set -a active -i 1 md0 > md0s1 has active set Thank you. Based on this, I take it the following two commands are equivalent? Old: bsdlabel -B ad0s1 New: gpart bootcode -b /boot/boot ad0s1 -- | 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 Fri Apr 23 10:29:58 2010 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 614081065670 for ; Fri, 23 Apr 2010 10:29:58 +0000 (UTC) (envelope-from scode@scode.org) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id F3EBF8FC1E for ; Fri, 23 Apr 2010 10:29:57 +0000 (UTC) Received: by wwa36 with SMTP id 36so6135625wwa.13 for ; Fri, 23 Apr 2010 03:29:56 -0700 (PDT) MIME-Version: 1.0 Sender: scode@scode.org Received: by 10.216.50.11 with HTTP; Fri, 23 Apr 2010 03:29:56 -0700 (PDT) X-Originating-IP: [90.232.37.142] In-Reply-To: <20100423082345.GA27379@icarus.home.lan> References: <20100423082345.GA27379@icarus.home.lan> Date: Fri, 23 Apr 2010 12:29:56 +0200 X-Google-Sender-Auth: f6da5beda32f0d04 Received: by 10.216.174.76 with SMTP id w54mr1551327wel.213.1272018596146; Fri, 23 Apr 2010 03:29:56 -0700 (PDT) Message-ID: From: Peter Schuller To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 10:29:58 -0000 > Supposedly we're supposed to use gpart(8) now, but I haven't figured out > how to use it in the same way as bsdlabel. And this avoids the problem by talking to GEOM via a published interface and having the kernel do the actual change, instead of writing directly to disk, correct? (I got that impression on a quick look.) -- / Peter Schuller From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 10:34:48 2010 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 CA86E106564A for ; Fri, 23 Apr 2010 10:34:48 +0000 (UTC) (envelope-from scode@scode.org) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2CC8FC18 for ; Fri, 23 Apr 2010 10:34:48 +0000 (UTC) Received: by wwa36 with SMTP id 36so6138381wwa.13 for ; Fri, 23 Apr 2010 03:34:47 -0700 (PDT) MIME-Version: 1.0 Sender: scode@scode.org Received: by 10.216.50.11 with HTTP; Fri, 23 Apr 2010 03:34:46 -0700 (PDT) X-Originating-IP: [90.232.37.142] In-Reply-To: <4BD1615E.9010909@yandex.ru> References: <20100423082345.GA27379@icarus.home.lan> <4BD1615E.9010909@yandex.ru> Date: Fri, 23 Apr 2010 12:34:46 +0200 X-Google-Sender-Auth: 0e9db29fabd2a699 Received: by 10.216.157.1 with SMTP id n1mr6825954wek.141.1272018886355; Fri, 23 Apr 2010 03:34:46 -0700 (PDT) Message-ID: From: Peter Schuller To: "Andrey V. Elsukov" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 10:34:48 -0000 > It's easy. Thank you for posting the example. I never really understood that gpart was to be the generic tool; I thought it was gpt specific. Obviously I should have read up better. Is gpart to be considered "tested", "stable", "production quality" and/or "default" now then, or is it still cutting edge/experimental? So for example, would it make sense to submit patches (not promising anything) to adjust the handbook and relegate disklabel to an historical artifact? -- / Peter Schuller From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 12:25:58 2010 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 0B522106564A for ; Fri, 23 Apr 2010 12:25:58 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5ED8FC1C for ; Fri, 23 Apr 2010 12:25:56 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA04773; Fri, 23 Apr 2010 15:25:52 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD191CF.40106@icyb.net.ua> Date: Fri, 23 Apr 2010 15:25:51 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Peter Schuller References: <20100423082345.GA27379@icarus.home.lan> <4BD1615E.9010909@yandex.ru> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 12:25:58 -0000 on 23/04/2010 13:34 Peter Schuller said the following: >> It's easy. > > Thank you for posting the example. I never really understood that > gpart was to be the generic tool; I thought it was gpt specific. > Obviously I should have read up better. > > Is gpart to be considered "tested", "stable", "production quality" > and/or "default" now then, or is it still cutting edge/experimental? Yes, it's "tested", "stable", "production quality" and/or "default". All other tools are slowly rotting now, but can be fixed to correctly works via GEOM interface the same way gpart does now. E.g. see Andrey's work on sade(8). > So for example, would it make sense to submit patches (not promising > anything) to adjust the handbook and relegate disklabel to an > historical artifact? gpart is the way to go and is the best tool to use on recent FreeBSD. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 13:00:12 2010 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 5DD711065672; Fri, 23 Apr 2010 13:00:12 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3DDC58FC17; Fri, 23 Apr 2010 13:00:11 +0000 (UTC) Received: by bwz27 with SMTP id 27so983814bwz.13 for ; Fri, 23 Apr 2010 06:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=Zo5tlGDyYRYZGIeURcX33caVehHPZxLs+5eGna5egm8=; b=L025U86bSaafEp5P5KLBMXHg1BDuYwMpPCx0tXEZHYEFXzdqaL4MLOAe1Jb8w8bA8J QLRXV4bUpojcJC/F+NFcFbblUJ/ySXnVT4UZw+gIsNd0Nz8eWO7B11/kjnC0JygYjH1+ qSDhMVTq8RWUmQ7hcp/oyiR0uvCM9JtpDcs/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=WO675OifQ0lPuXE7RPiAvQHcDKOkBuchIVR/H13XMMdoAxhERJvre5doxLWB3XbRim DtbLHMk+oGg96YspSGJGBls0ZJDd/NVEhDxr8USRoT571hGtGn1Tsicf1fWpOhfNzmBQ 88yFNwK0/OAttEYXU+TIuUDoqeY2N/eVRuU6s= Received: by 10.204.33.149 with SMTP id h21mr268356bkd.203.1272027609542; Fri, 23 Apr 2010 06:00:09 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 16sm521651bwz.5.2010.04.23.06.00.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 06:00:08 -0700 (PDT) From: Mikolaj Golub To: Pawel Jakub Dawidek Organization: TOA Ukraine References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> Date: Fri, 23 Apr 2010 16:00:05 +0300 In-Reply-To: <20100423062950.GD1670@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Fri, 23 Apr 2010 08:29:50 +0200") Message-ID: <86k4rye33e.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 23 Apr 2010 13:00:12 -0000 On Fri, 23 Apr 2010 08:29:50 +0200 Pawel Jakub Dawidek wrote: PJD> On Wed, Apr 21, 2010 at 12:02:16PM +0300, Mikolaj Golub wrote: >> I interpret this in the following way. Although the network is down >> hast_proto_send() in remote_send_thread() returns success (sent data are >> stored in the kernel buffer). Then kernel tries to send data and eventually >> fails after timeout and close the socket. hastd is not aware about this, >> remote_send_thread() is blocked in "Taking request" at this time, sync thread >> is waiting for status from the secondary about sent data but secondary does >> not send it because it did not receive any data. PJD> "Taking request" only means that HAST is waiting for a request. In case PJD> of ggate_send thread it means it is waiting for I/O request from the PJD> kernel. It stops here, because there is no new request. >> Restarting hastd on the secondary usually helps. A workaround is to set >> net.inet.tcp.keepidle to some small value (e.g. 300 sec) on the >> secondary. Then the secondary will notice much earlier that the peer has >> closed the connection and will restart the worker itself: >> >> Apr 21 11:52:21 hastb hastd: [storage] (secondary) Unable to receive request header: Connection reset by peer. >> Apr 21 11:52:21 hastb hastd: [storage] (secondary) Worker process (pid=1398) exited ungracefully: status=19200. PJD> What you are observing here is because currently there is no keep-alive PJD> mechanism in hastd, so if there are no I/O requests, primary won't PJD> notice that secondary is down until next I/O request arrives. PJD> I don't consider it critical, but confusing. Note that when secondary PJD> goes down and there are no I/O requests to primary, there will be PJD> nothing to synchronize, so fast reconnect isn't crucial in this case. PJD> We need one I/O request coming to primary to discover that secondary is PJD> down and start reconnect loop. This does not look for me just "confusing" :-). When I wrote that hast had gotten stuck I meant that all operations with FS above hast (ZFS in my case) had hanged and this lasted until hastd on the secondary was restarted. May be I miss something but I think the following happens when there is network outage: remote_send_thread(): 1) the request is moved to recv queue; 2) the request is sent to secondary calling hast_proto_send(); 3) hast_proto_send() returns OK although data are not sent yet (they are buffered by kernel) so the request is not removed from recv queue and not moved immediately to done queue as it would be in the case when hast_proto_send() returned error. The kernel is trying to send the request for some time, fails by timeout and close the connection. remote_recv_thread(): 1) takes the request from recv queue; 2) waits for the respond from the secondary in hast_proto_recv_hdr() which will never come because the secondary has not received the request and has nothing to reply. So we have a request or several gotten stuck in in the recv queue. It looks like FS is waiting for the response on this request(s) sent by ggate_send_thread() and gets stuck. Below are logs for a similar example I made today: The last messages before "outage": Apr 23 14:10:20 hasta hastd: [storage] (primary) ggate_send: (0x28411c40) Got request. Apr 23 14:10:20 hasta hastd: [storage] (primary) ggate_send: (0x28411c40) Moving request to the free queue. Apr 23 14:10:20 hasta hastd: [storage] (primary) ggate_send: Taking request. During "outage": Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c80) Request received from the kernel: WRITE(1925971968, 131072). Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c80) Moving request to the send queues. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0) Got free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0) Waiting for request from the kernel. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0) Request received from the kernel: WRITE(1925348352, 1024). Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0) Moving request to the send queues. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00) Got free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00) Waiting for request from the kernel. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00) Request received from the kernel: WRITE(922860544, 1024). Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411c80) Got request. Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411c80) Got request. Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411c80) Moving request to the recv queue. Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: Taking request. Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411cc0) Got request. Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411cc0) Moving request to the recv queue. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00) Moving request to the send queues. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0) Got free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0) Waiting for request from the kernel. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0) Request received from the kernel: WRITE(1926103040, 131072). Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0) Moving request to the send queues. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80) Got free request. Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80) Waiting for request from the kernel. Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking request. Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411cc0) Got request. Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking request. Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411c00) Got request. Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking request. Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411bc0) Got request. Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking request. During "outage" two requests 0x28411c80 and 0x28411cc0 was received, remote_send reported that it had succesfully sent the requests and moved them to recv queue. And the requests got stuck there (gdb) p hio_recv_list[1].tqh_first $42 = (struct hio *) 0x28411c80 (gdb) p *hio_recv_list[1].tqh_first->hio_next $43 = {tqe_next = 0x28411cc0, tqe_prev = 0x284eb240} (gdb) p *hio_recv_list[1].tqh_first $44 = {hio_countdown = 1, hio_errors = 0x284c93b0, hio_ggio = {gctl_version = 2, gctl_unit = 0, gctl_seq = 5027, gctl_cmd = 2, gctl_offset = 1925971968, gctl_length = 131072, gctl_data = 0x29144000, gctl_error = 0}, hio_next = 0x284eb810} (gdb) p *hio_recv_list[1].tqh_first->hio_next->tqe_next $45 = {hio_countdown = 1, hio_errors = 0x284c93b8, hio_ggio = {gctl_version = 2, gctl_unit = 0, gctl_seq = 5028, gctl_cmd = 2, gctl_offset = 1925348352, gctl_length = 1024, gctl_data = 0x29164000, gctl_error = 0}, hio_next = 0x284eb820} After this there were no messages at all even after recovering the connectivity between the hosts. The backtrace: Thread 8 (Thread 28404140 (LWP 100041)): #0 0x2823edd7 in __error () from /lib/libthr.so.3 #1 0x2823e9b8 in __error () from /lib/libthr.so.3 #2 0x284c3520 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284c3500 in ?? () #6 0x00000000 in ?? () #7 0x08066480 in ?? () #8 0xbfbfeb58 in ?? () #9 0x2823d31f in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x2823cbbe in pthread_cond_signal () from /lib/libthr.so.3 #11 0x08058e68 in cv_wait (cv=0x8067e2c, lock=0x8067e28) at synch.h:125 #12 0x0805b74e in cv_timedwait (cv=0x8067e2c, lock=0x8067e28, timeout=0) at synch.h:135 #13 0x0805b71c in guard_thread (arg=0x284cab00) at /usr/src/sbin/hastd/primary.c:1787 #14 0x080581f6 in hastd_primary (res=0x284cab00) at /usr/src/sbin/hastd/primary.c:773 #15 0x0804c4e8 in control_set_role (cfg=0x8066500, nvout=0x284eb0b0, role=2 '\002', res=0x284cab00, name=0x28481442 "storage", no=0) at /usr/src/sbin/hastd/control.c:114 #16 0x0804cd01 in control_handle (cfg=0x8066500) at /usr/src/sbin/hastd/control.c:332 #17 0x0804f06c in main_loop () at /usr/src/sbin/hastd/hastd.c:424 #18 0x0804f3d8 in main (argc=0, argv=0xbfbfee90) at /usr/src/sbin/hastd/hastd.c:520 Thread 7 (Thread 28404280 (LWP 100070)): #0 0x28344773 in ioctl () from /lib/libc.so.7 #1 0x080588b4 in ggate_recv_thread (arg=0x284cab00) at /usr/src/sbin/hastd/primary.c:894 #2 0x2823428f in pthread_getprio () from /lib/libthr.so.3 #3 0x00000000 in ?? () Thread 6 (Thread 284043c0 (LWP 100085)): #0 0x2823edd7 in __error () from /lib/libthr.so.3 #1 0x2823e9b8 in __error () from /lib/libthr.so.3 #2 0x284c32a0 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284c3280 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0x00000000 in ?? () #9 0x2823d31f in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x2823cbbe in pthread_cond_signal () from /lib/libthr.so.3 #11 0x08058e68 in cv_wait (cv=0x284c9080, lock=0x284c9078) at synch.h:125 #12 0x08058f27 in local_send_thread (arg=0x284cab00) at /usr/src/sbin/hastd/primary.c:1032 #13 0x2823428f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 5 (Thread 28404500 (LWP 100086)): #0 0x2823edd7 in __error () from /lib/libthr.so.3 #1 0x2823e670 in __error () from /lib/libthr.so.3 #2 0x284300a0 in ?? () #3 0x0000000d in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () ---Type to continue, or q to quit--- #7 0x28404500 in ?? () #8 0xbf7fcee8 in ?? () #9 0x282384b1 in pthread_rwlock_init () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) Thread 4 (Thread 28404640 (LWP 100087)): #0 0x282faa57 in recvfrom () from /lib/libc.so.7 #1 0x28280be2 in recv () from /lib/libc.so.7 #2 0x0805c277 in proto_common_recv (fd=10, data=0xbf6fbf27 "", size=5) at /usr/src/sbin/hastd/proto_common.c:78 #3 0x0805d4e0 in tcp4_recv (ctx=0x28417580, data=0xbf6fbf27 "", size=5) at /usr/src/sbin/hastd/proto_tcp4.c:325 #4 0x0805bde1 in proto_recv (conn=0x2a3f9180, data=0xbf6fbf27, size=5) at /usr/src/sbin/hastd/proto.c:198 #5 0x0804ddae in hast_proto_recv_hdr (conn=0x2a3f9180, nvp=0xbf6fbf7c) at /usr/src/sbin/hastd/hast_proto.c:298 #6 0x08059ee9 in remote_recv_thread (arg=0x284cab00) at /usr/src/sbin/hastd/primary.c:1282 #7 0x2823428f in pthread_getprio () from /lib/libthr.so.3 #8 0x00000000 in ?? () Thread 3 (Thread 28404780 (LWP 100088)): #0 0x2823edd7 in __error () from /lib/libthr.so.3 #1 0x2823e9b8 in __error () from /lib/libthr.so.3 #2 0x284c34a0 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284c3480 in ?? () #6 0x00000000 in ?? () #7 0x28404780 in ?? () #8 0xbf5faec8 in ?? () #9 0x2823d31f in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x2823cbbe in pthread_cond_signal () from /lib/libthr.so.3 #11 0x08058e68 in cv_wait (cv=0x8067e14, lock=0x8067e10) at synch.h:125 #12 0x0805a3fb in ggate_send_thread (arg=0x284cab00) at /usr/src/sbin/hastd/primary.c:1383 #13 0x2823428f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 2 (Thread 284048c0 (LWP 100089)): #0 0x2823edd7 in __error () from /lib/libthr.so.3 #1 0x2823e9b8 in __error () from /lib/libthr.so.3 #2 0x284c31a0 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x284c3180 in ?? () #6 0x00000000 in ?? () #7 0x00000000 in ?? () #8 0xbf4f9ea8 in ?? () #9 0x2823d31f in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x2823cbbe in pthread_cond_signal () from /lib/libthr.so.3 #11 0x08058e68 in cv_wait (cv=0x8067e20, lock=0x8067e1c) at synch.h:125 #12 0x0805a7bc in sync_thread (arg=0x284cab00) at /usr/src/sbin/hastd/primary.c:1472 #13 0x2823428f in pthread_getprio () from /lib/libthr.so.3 #14 0x00000000 in ?? () Thread 1 (Thread 28404a00 (LWP 100090)): #0 0x282faa55 in recvfrom () from /lib/libc.so.7 #1 0x28280be2 in recv () from /lib/libc.so.7 ---Type to continue, or q to quit--- #2 0x0805c277 in proto_common_recv (fd=9, data=0xbf3f8f47 "*", size=5) at /usr/src/sbin/hastd/proto_common.c:78 #3 0x0805c69e in sp_recv (ctx=0x284eb190, data=0xbf3f8f47 "*", size=5) at /usr/src/sbin/hastd/proto_socketpair.c:177 #4 0x0805bde1 in proto_recv (conn=0x284eb170, data=0xbf3f8f47, size=5) at /usr/src/sbin/hastd/proto.c:198 #5 0x0804ddae in hast_proto_recv_hdr (conn=0x284eb170, nvp=0xbf3f8f80) at /usr/src/sbin/hastd/hast_proto.c:298 #6 0x0804ce27 in ctrl_thread (arg=0x284cab00) at /usr/src/sbin/hastd/control.c:373 #7 0x2823428f in pthread_getprio () from /lib/libthr.so.3 #8 0x00000000 in ?? () #0 0x282faa57 in recvfrom () from /lib/libc.so.7 PJD> Could you confirm this is what you are observing? If not, what FreeBSD PJD> version do you use? If it is HEAD, do you have r205738? Yes I read the thread started by Kevin Day :-) and this was the first thing I checked. I am using CURRENT. -- Mikolaj Golub From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 13:09:33 2010 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 7CDB9106566B for ; Fri, 23 Apr 2010 13:09:33 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by mx1.freebsd.org (Postfix) with ESMTP id 162438FC08 for ; Fri, 23 Apr 2010 13:09:32 +0000 (UTC) Received: by bwz27 with SMTP id 27so993403bwz.13 for ; Fri, 23 Apr 2010 06:09:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.213.18 with HTTP; Fri, 23 Apr 2010 05:42:39 -0700 (PDT) In-Reply-To: <4BD191CF.40106@icyb.net.ua> References: <20100423082345.GA27379@icarus.home.lan> <4BD1615E.9010909@yandex.ru> <4BD191CF.40106@icyb.net.ua> Date: Fri, 23 Apr 2010 22:42:39 +1000 Received: by 10.102.16.24 with SMTP id 24mr3319473mup.121.1272026559738; Fri, 23 Apr 2010 05:42:39 -0700 (PDT) Message-ID: From: Antony Mawer To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 13:09:33 -0000 On Fri, Apr 23, 2010 at 10:25 PM, Andriy Gapon wrote: > on 23/04/2010 13:34 Peter Schuller said the following: >>> It's easy. >> >> Thank you for posting the example. I never really understood that >> gpart was to be the generic tool; I thought it was gpt specific. >> Obviously I should have read up better. >> >> Is gpart to be considered "tested", "stable", "production quality" >> and/or "default" now then, or is it still cutting edge/experimental? > > Yes, it's "tested", "stable", "production quality" and/or "default". ... > gpart is the way to go and is the best tool to use on recent FreeBSD. Agreed. Having just gone through updating $work's installer to use gpart instead, it makes partitioning so much more pleasant and consistent than previous tools... --Antony From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 13:12:56 2010 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 1A9E1106566B for ; Fri, 23 Apr 2010 13:12:56 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id B91FA8FC18 for ; Fri, 23 Apr 2010 13:12:55 +0000 (UTC) Received: by qyk11 with SMTP id 11so11413122qyk.13 for ; Fri, 23 Apr 2010 06:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=8KmBI8fLZ3K/9VhWAawL/lvGj/0omFDnfq3ICSNk55M=; b=xu5dpz5ykWgE973nZKTPWnGJPMXA+JoaFgRi1WikWX4YrDE8rtyPhmhkkulNsBYAb5 DW7ljo4KARIsbvOKIeX01QuxIsZnKVTx3AEHETD/NDpghyxlZ1REj5DyVhjeg+HWxatw ziIAVROblpCZFQvNXGEsZ4kAwQprIZk5kRdxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=duap2EdXgmhLy3BhoRRjuEmCgm7rPabGnIuwcG235IXzG9Te+AKRAp7B2jVGCoNGi7 ydFawtPgSE/0Yb+EeEb+OPZyidA2JXjMDIiXki2RZIdqksLLdakxzH8oo4Y2zLK3ZnaA upxPK7cbg0pLPiDjuIoDkWGben6slN7JEdQeo= Received: by 10.224.43.132 with SMTP id w4mr10008qae.19.1272028374951; Fri, 23 Apr 2010 06:12:54 -0700 (PDT) Received: from centel.dataix.local (c-71-205-129-194.hsd1.mi.comcast.net [71.205.129.194]) by mx.google.com with ESMTPS id 2sm3847433qwi.49.2010.04.23.06.12.53 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 06:12:53 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BD19CD1.1070707@dataix.net> Date: Fri, 23 Apr 2010 09:12:49 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <20100423082345.GA27379@icarus.home.lan> <4BD1615E.9010909@yandex.ru> In-Reply-To: <4BD1615E.9010909@yandex.ru> X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------040506030104030005030503" Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 13:12:56 -0000 This is a multi-part message in MIME format. --------------040506030104030005030503 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit On 04/23/2010 04:59, Andrey V. Elsukov wrote: > On 23.04.2010 12:23, Jeremy Chadwick wrote: >> Supposedly we're supposed to use gpart(8) now, but I haven't figured out >> how to use it in the same way as bsdlabel. > > It's easy. > > # gpart create -s mbr md0 > md0 created > # gpart add -t freebsd md0 > md0s1 added > # gpart create -s bsd md0s1 > md0s1 created > # gpart add -t freebsd-ufs -s 50m md0s1 > md0s1a added > # gpart add -t freebsd-swap md0s1 > md0s1b added > # gpart bootcode -b /boot/boot md0s1 > md0s1 has bootcode > # gpart bootcode -b /boot/mbr md0 > md0 has bootcode > # gpart set -a active -i 1 md0 > md0s1 has active set > > As a curious question. I seem to remember a thread that discussed the need to specify -b & -s to to "add". I recall this being fixed in more recent versions i.e. >= 8.X. Does anyone know if these changes can be MFC'd to stable/7 ? Attached is a diff I just generated "stable/7/sbin/geom/class/part -> stable/8/sbin/geom/class/part" as of recent commit r207113. Thanks -- jhell --------------040506030104030005030503 Content-Type: text/plain; name="gpart.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gpart.diff" Index: geom_part.c =================================================================== --- geom_part.c (.../7/sbin/geom/class/part) (revision 207113) +++ geom_part.c (.../8/sbin/geom/class/part) (revision 207113) @@ -55,6 +55,7 @@ uint32_t PUBSYM(lib_version) = G_LIB_VERSION; uint32_t PUBSYM(version) = 0; +static char autofill[] = "*"; static char optional[] = ""; static char flags[] = "C"; @@ -68,10 +69,10 @@ struct g_command PUBSYM(class_commands)[] = { { "add", 0, gpart_issue, { - { 'b', "start", NULL, G_TYPE_STRING }, - { 's', "size", NULL, G_TYPE_STRING }, + { 'b', "start", autofill, G_TYPE_ASCLBA }, + { 's', "size", autofill, G_TYPE_ASCLBA }, { 't', "type", NULL, G_TYPE_STRING }, - { 'i', index_param, optional, G_TYPE_STRING }, + { 'i', index_param, optional, G_TYPE_ASCNUM }, { 'l', "label", optional, G_TYPE_STRING }, { 'f', "flags", flags, G_TYPE_STRING }, G_OPT_SENTINEL }, @@ -80,7 +81,7 @@ { "bootcode", 0, gpart_bootcode, { { 'b', bootcode_param, optional, G_TYPE_STRING }, { 'p', partcode_param, optional, G_TYPE_STRING }, - { 'i', index_param, optional, G_TYPE_STRING }, + { 'i', index_param, optional, G_TYPE_ASCNUM }, { 'f', "flags", flags, G_TYPE_STRING }, G_OPT_SENTINEL }, "geom", NULL @@ -88,13 +89,13 @@ { "commit", 0, gpart_issue, G_NULL_OPTS, "geom", NULL }, { "create", 0, gpart_issue, { { 's', "scheme", NULL, G_TYPE_STRING }, - { 'n', "entries", optional, G_TYPE_STRING }, + { 'n', "entries", optional, G_TYPE_ASCNUM }, { 'f', "flags", flags, G_TYPE_STRING }, G_OPT_SENTINEL }, "provider", NULL }, { "delete", 0, gpart_issue, { - { 'i', index_param, NULL, G_TYPE_STRING }, + { 'i', index_param, NULL, G_TYPE_ASCNUM }, { 'f', "flags", flags, G_TYPE_STRING }, G_OPT_SENTINEL }, "geom", NULL @@ -104,7 +105,7 @@ G_OPT_SENTINEL }, "geom", NULL }, { "modify", 0, gpart_issue, { - { 'i', index_param, NULL, G_TYPE_STRING }, + { 'i', index_param, NULL, G_TYPE_ASCNUM }, { 'l', "label", optional, G_TYPE_STRING }, { 't', "type", optional, G_TYPE_STRING }, { 'f', "flags", flags, G_TYPE_STRING }, @@ -113,7 +114,7 @@ }, { "set", 0, gpart_issue, { { 'a', "attrib", NULL, G_TYPE_STRING }, - { 'i', index_param, NULL, G_TYPE_STRING }, + { 'i', index_param, NULL, G_TYPE_ASCNUM }, { 'f', "flags", flags, G_TYPE_STRING }, G_OPT_SENTINEL }, "geom", NULL @@ -127,7 +128,7 @@ { "undo", 0, gpart_issue, G_NULL_OPTS, "geom", NULL }, { "unset", 0, gpart_issue, { { 'a', "attrib", NULL, G_TYPE_STRING }, - { 'i', index_param, NULL, G_TYPE_STRING }, + { 'i', index_param, NULL, G_TYPE_ASCNUM }, { 'f', "flags", flags, G_TYPE_STRING }, G_OPT_SENTINEL }, "geom", NULL @@ -240,6 +241,131 @@ return (buf); } +static int +gpart_autofill(struct gctl_req *req) +{ + struct gmesh mesh; + struct gclass *cp; + struct ggeom *gp; + struct gprovider *pp; + unsigned long long first, last; + unsigned long long size, start; + unsigned long long lba, len, grade; + const char *s; + char *val; + int error, has_size, has_start; + + s = gctl_get_ascii(req, "verb"); + if (strcmp(s, "add") != 0) + return (0); + + s = gctl_get_ascii(req, "size"); + has_size = (*s == '*') ? 0 : 1; + size = (has_size) ? (unsigned long long)atoll(s) : 0ULL; + + s = gctl_get_ascii(req, "start"); + has_start = (*s == '*') ? 0 : 1; + start = (has_start) ? (unsigned long long)atoll(s) : ~0ULL; + + /* No autofill necessary. */ + if (has_size && has_start) + return (0); + + error = geom_gettree(&mesh); + if (error) + return (error); + s = gctl_get_ascii(req, "class"); + if (s == NULL) + abort(); + cp = find_class(&mesh, s); + if (cp == NULL) + errx(EXIT_FAILURE, "Class %s not found.", s); + s = gctl_get_ascii(req, "geom"); + if (s == NULL) + abort(); + gp = find_geom(cp, s); + if (gp == NULL) + errx(EXIT_FAILURE, "No such geom: %s.", s); + first = atoll(find_geomcfg(gp, "first")); + last = atoll(find_geomcfg(gp, "last")); + grade = ~0ULL; + while ((pp = find_provider(gp, first)) != NULL) { + s = find_provcfg(pp, "start"); + if (s == NULL) { + s = find_provcfg(pp, "offset"); + lba = atoll(s) / pp->lg_sectorsize; + } else + lba = atoll(s); + + if (first < lba) { + /* Free space [first, lba> */ + len = lba - first; + if (has_size) { + if (len >= size && len - size < grade) { + start = first; + grade = len - size; + } + } else if (has_start) { + if (start >= first && start < lba) { + size = lba - start; + grade = start - first; + } + } else { + if (grade == ~0ULL || len > size) { + start = first; + size = len; + grade = 0; + } + } + } + + s = find_provcfg(pp, "end"); + if (s == NULL) { + s = find_provcfg(pp, "length"); + first = lba + atoll(s) / pp->lg_sectorsize; + } else + first = atoll(s) + 1; + } + if (first <= last) { + /* Free space [first-last] */ + len = last - first + 1; + if (has_size) { + if (len >= size && len - size < grade) { + start = first; + grade = len - size; + } + } else if (has_start) { + if (start >= first && start <= last) { + size = last - start + 1; + grade = start - first; + } + } else { + if (grade == ~0ULL || len > size) { + start = first; + size = len; + grade = 0; + } + } + } + + if (grade == ~0ULL) + return (ENOSPC); + + if (!has_size) { + asprintf(&val, "%llu", size); + if (val == NULL) + return (ENOMEM); + gctl_change_param(req, "size", -1, val); + } + if (!has_start) { + asprintf(&val, "%llu", start); + if (val == NULL) + return (ENOMEM); + gctl_change_param(req, "start", -1, val); + } + return (0); +} + static void gpart_show_geom(struct ggeom *gp, const char *element) { @@ -420,6 +546,8 @@ errx(EXIT_FAILURE, "Class %s not found.", s); } s = gctl_get_ascii(req, "geom"); + if (s == NULL) + abort(); gp = find_geom(classp, s); if (gp == NULL) errx(EXIT_FAILURE, "No such geom: %s.", s); @@ -531,6 +659,14 @@ const char *errstr; int error, status; + /* autofill parameters (if applicable). */ + error = gpart_autofill(req); + if (error) { + warnc(error, "autofill"); + status = EXIT_FAILURE; + goto done; + } + bzero(buf, sizeof(buf)); gctl_rw_param(req, "output", sizeof(buf), buf); errstr = gctl_issue(req); Property changes on: . ___________________________________________________________________ Deleted: svn:mergeinfo Reverse-merged /head/sbin/geom/class/part:r172506-173080,173082-178817,178819-179854,183718,184070,185038,185044,185046,185057,185454,185495-185496,186843,187067,188017,188330,197274,200282,200290,201432,203505 --------------040506030104030005030503-- From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 13:34:24 2010 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 E04CB106566B for ; Fri, 23 Apr 2010 13:34:24 +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 B146E8FC1B for ; Fri, 23 Apr 2010 13:34:24 +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 651E846B99; Fri, 23 Apr 2010 09:34:24 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C5B928A025; Fri, 23 Apr 2010 09:34:22 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Fri, 23 Apr 2010 08:44:58 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BD191CF.40106@icyb.net.ua> In-Reply-To: <4BD191CF.40106@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201004230844.58047.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 23 Apr 2010 09:34:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andriy Gapon Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 13:34:25 -0000 On Friday 23 April 2010 8:25:51 am Andriy Gapon wrote: > on 23/04/2010 13:34 Peter Schuller said the following: > >> It's easy. > > > > Thank you for posting the example. I never really understood that > > gpart was to be the generic tool; I thought it was gpt specific. > > Obviously I should have read up better. > > > > Is gpart to be considered "tested", "stable", "production quality" > > and/or "default" now then, or is it still cutting edge/experimental? > > Yes, it's "tested", "stable", "production quality" and/or "default". > All other tools are slowly rotting now, but can be fixed to correctly works via > GEOM interface the same way gpart does now. > E.g. see Andrey's work on sade(8). Actually, the other tools were already fixed to work properly with GEOM, but they used the older set of GEOM classes (GEOM_BSD, GEOM_MBR, etc.) instead of the GEOM_PART classes. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 14:25:01 2010 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 17DD41065675; Fri, 23 Apr 2010 14:25:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 098DE8FC0A; Fri, 23 Apr 2010 14:24:59 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA07704; Fri, 23 Apr 2010 17:24:57 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BD1ADB8.2060405@icyb.net.ua> Date: Fri, 23 Apr 2010 17:24:56 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: John Baldwin References: <4BD191CF.40106@icyb.net.ua> <201004230844.58047.jhb@freebsd.org> In-Reply-To: <201004230844.58047.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 14:25:01 -0000 on 23/04/2010 15:44 John Baldwin said the following: > Actually, the other tools were already fixed to work properly with GEOM, but > they used the older set of GEOM classes (GEOM_BSD, GEOM_MBR, etc.) instead > of the GEOM_PART classes. Yes. Thanks for the clarification! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 15:19:06 2010 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 4EF80106566B for ; Fri, 23 Apr 2010 15:19:06 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id CBDE58FC15 for ; Fri, 23 Apr 2010 15:19:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O5Kem-0005gF-D4 for freebsd-fs@freebsd.org; Fri, 23 Apr 2010 17:19:04 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2010 17:19:04 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Apr 2010 17:19:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org connect(): No such file or directory From: Ivan Voras Date: Fri, 23 Apr 2010 17:18:58 +0200 Lines: 30 Message-ID: References: <4BD191CF.40106@icyb.net.ua> <201004230844.58047.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 In-Reply-To: <201004230844.58047.jhb@freebsd.org> X-Enigmail-Version: 1.0.1 Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 15:19:06 -0000 On 04/23/10 14:44, John Baldwin wrote: > On Friday 23 April 2010 8:25:51 am Andriy Gapon wrote: >> on 23/04/2010 13:34 Peter Schuller said the following: >>>> It's easy. >>> >>> Thank you for posting the example. I never really understood that >>> gpart was to be the generic tool; I thought it was gpt specific. >>> Obviously I should have read up better. >>> >>> Is gpart to be considered "tested", "stable", "production quality" >>> and/or "default" now then, or is it still cutting edge/experimental? >> >> Yes, it's "tested", "stable", "production quality" and/or "default". >> All other tools are slowly rotting now, but can be fixed to correctly works via >> GEOM interface the same way gpart does now. >> E.g. see Andrey's work on sade(8). > > Actually, the other tools were already fixed to work properly with GEOM, but > they used the older set of GEOM classes (GEOM_BSD, GEOM_MBR, etc.) instead > of the GEOM_PART classes. It also depends on the meaning of "fixed" :) They mostly wrote to disk drives directly from userland and relied on GEOM to pick up the changes via the "spoil" mechanism - which is why they couldn't write to partition tables if a file system on one of the partition was mounted, etc., requiring hacks like kern.geom.debugflags=16 to drop the permission (actually reference counting) checks. Gpart has a kernel-userland interface so that the userland part(s) tell the kernel what they need and the kernel does the writing (if applicable). From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 19:58:19 2010 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 1CF5E106564A for ; Fri, 23 Apr 2010 19:58:19 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id ABF328FC18 for ; Fri, 23 Apr 2010 19:58:18 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX1+EIf5mHYpUFt9/CNcEecr2cwtHOMRq3CE@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with ESMTP id o3NJw9Qc018202; Fri, 23 Apr 2010 20:58:09 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o3NJw93Q031025; Fri, 23 Apr 2010 20:58:09 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o3NJw9hN031022; Fri, 23 Apr 2010 20:58:09 +0100 Date: Fri, 23 Apr 2010 20:58:09 +0100 Message-Id: <201004231958.o3NJw9hN031022@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org, avg@icyb.net.ua In-reply-to: <201004230844.58047.jhb@freebsd.org> (message from John Baldwin on Fri, 23 Apr 2010 08:44:58 -0400) References: <4BD191CF.40106@icyb.net.ua> <201004230844.58047.jhb@freebsd.org> Cc: Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 19:58:19 -0000 >>>>> On Fri, 23 Apr 2010 08:44:58 -0400, John Baldwin said: > > On Friday 23 April 2010 8:25:51 am Andriy Gapon wrote: > > on 23/04/2010 13:34 Peter Schuller said the following: > > >> It's easy. > > > > > > Thank you for posting the example. I never really understood that > > > gpart was to be the generic tool; I thought it was gpt specific. > > > Obviously I should have read up better. > > > > > > Is gpart to be considered "tested", "stable", "production quality" > > > and/or "default" now then, or is it still cutting edge/experimental? > > > > Yes, it's "tested", "stable", "production quality" and/or "default". > > All other tools are slowly rotting now, but can be fixed to correctly works via > > GEOM interface the same way gpart does now. > > E.g. see Andrey's work on sade(8). > > Actually, the other tools were already fixed to work properly with GEOM, but > they used the older set of GEOM classes (GEOM_BSD, GEOM_MBR, etc.) instead > of the GEOM_PART classes. Ironically, disklabel is using GEOM, but sysinstall and sade are still using libdisk which does direct I/O...and also generates different BSD labels from GEOM_PART. __Martin From owner-freebsd-fs@FreeBSD.ORG Fri Apr 23 20:09:33 2010 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 C3C68106564A for ; Fri, 23 Apr 2010 20:09:33 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 61DBB8FC17 for ; Fri, 23 Apr 2010 20:09:33 +0000 (UTC) Received: from higson.cam.lispworks.com (IDENT:U2FsdGVkX1+6Yi5If2Omggbp9H1r3tEr0VBxAX6I914@higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.12.9p2/8.12.9) with ESMTP id o3NK9OQc018893; Fri, 23 Apr 2010 21:09:24 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com by higson.cam.lispworks.com (8.13.1) id o3NK9O4a031129; Fri, 23 Apr 2010 21:09:24 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.13.1/8.13.1/Submit) id o3NK9OJB031126; Fri, 23 Apr 2010 21:09:24 +0100 Date: Fri, 23 Apr 2010 21:09:24 +0100 Message-Id: <201004232009.o3NK9OJB031126@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: <20100423090227.GA29149@icarus.home.lan> (message from Jeremy Chadwick on Fri, 23 Apr 2010 02:02:27 -0700) References: <20100423082345.GA27379@icarus.home.lan> <4BD1615E.9010909@yandex.ru> <20100423090227.GA29149@icarus.home.lan> Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device 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, 23 Apr 2010 20:09:33 -0000 >>>>> On Fri, 23 Apr 2010 02:02:27 -0700, Jeremy Chadwick said: > > Thank you. Based on this, I take it the following two commands are > equivalent? > > Old: bsdlabel -B ad0s1 > New: gpart bootcode -b /boot/boot ad0s1 Yes, they should be. __Martin From owner-freebsd-fs@FreeBSD.ORG Sat Apr 24 07:07:44 2010 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 0CA2E106564A for ; Sat, 24 Apr 2010 07:07:44 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4E5018FC15 for ; Sat, 24 Apr 2010 07:07:42 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 21C1B45EC0; Sat, 24 Apr 2010 09:07:41 +0200 (CEST) Received: from localhost (gate.wheel.pl [10.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 9006B45E97; Sat, 24 Apr 2010 09:07:36 +0200 (CEST) Date: Sat, 24 Apr 2010 09:07:37 +0200 From: Pawel Jakub Dawidek To: "hiroshi@soupacific.com" Message-ID: <20100424070737.GC3067@garage.freebsd.pl> References: <20100416065126.GG1705@garage.freebsd.pl> <4BCD3979.8050107@soupacific.com> <4BCD5AD7.8070502@soupacific.com> <4BCFA4C2.6000109@soupacific.com> <4BCFB1C5.5000908@soupacific.com> <4BD01800.9040901@soupacific.com> <4BD0438B.5080308@soupacific.com> <4BD0E432.1000108@soupacific.com> <20100423061521.GC1670@garage.freebsd.pl> <4BD24E16.8000302@soupacific.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XuV1QlJbYrcVoo+x" Content-Disposition: inline In-Reply-To: <4BD24E16.8000302@soupacific.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: HAST configuration? 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, 24 Apr 2010 07:07:44 -0000 --XuV1QlJbYrcVoo+x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 24, 2010 at 10:49:10AM +0900, hiroshi@soupacific.com wrote: > Hi ! >=20 > I checked ucarp_up.sh and modified like this. >=20 > # Wait few seconds for provider to appear. > ##for i in `jot 50`; do > for i in `jot 2000`; do > [ -c "${device}" ] && break > sleep 0.1 > done >=20 > Then 30 seconds to a minute after login the box, /dev/hast and /hapool=20 > appears. >=20 > So hastctl role primary test takes a while when nodeb is downed. >=20 > I hope this info help you some. That makes sense. Connection attempts are made in background, but with one exception - role change. When the role is changed to primary I try to connect to secondary _before_ creating /dev/hast/ provider, so if secondary is fine, we will connect and everything will work. I wanted to avoid situation where we create /dev/hast/ provider, system will start to use it and we will connect to secondary a bit later. This will trigger synchronization, which isn't desiriable when both nodes are in good shape. I think the way to fix it is would be to decrease initial connection timeout. I'll look into this. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --XuV1QlJbYrcVoo+x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvSmLkACgkQForvXbEpPzSZJwCdHhHVXDiwomU77Ou9cGoylSdM lUoAn2PwvgZoYsREo2PIOVo0PW8bPBf6 =P6wc -----END PGP SIGNATURE----- --XuV1QlJbYrcVoo+x-- From owner-freebsd-fs@FreeBSD.ORG Sat Apr 24 07:30:43 2010 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 233361065672 for ; Sat, 24 Apr 2010 07:30:43 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7228FC14 for ; Sat, 24 Apr 2010 07:30:41 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 20EC745CD8; Sat, 24 Apr 2010 09:30:39 +0200 (CEST) Received: from localhost (gate.wheel.pl [10.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E763045C8C; Sat, 24 Apr 2010 09:30:30 +0200 (CEST) Date: Sat, 24 Apr 2010 09:30:31 +0200 From: Pawel Jakub Dawidek To: Mikolaj Golub Message-ID: <20100424073031.GD3067@garage.freebsd.pl> References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7mxbaLlpDEyR1+x6" Content-Disposition: inline In-Reply-To: <86k4rye33e.fsf@zhuzha.ua1> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 24 Apr 2010 07:30:43 -0000 --7mxbaLlpDEyR1+x6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2010 at 04:00:05PM +0300, Mikolaj Golub wrote: > This does not look for me just "confusing" :-). When I wrote that hast had > gotten stuck I meant that all operations with FS above hast (ZFS in my ca= se) > had hanged and this lasted until hastd on the secondary was restarted. Ok, I see. > May be I miss something but I think the following happens when there is > network outage: >=20 > remote_send_thread(): >=20 > 1) the request is moved to recv queue; >=20 > 2) the request is sent to secondary calling hast_proto_send(); >=20 > 3) hast_proto_send() returns OK although data are not sent yet (they are > buffered by kernel) so the request is not removed from recv queue and not > moved immediately to done queue as it would be in the case when > hast_proto_send() returned error. >=20 > The kernel is trying to send the request for some time, fails by timeout = and > close the connection. >=20 > remote_recv_thread(): >=20 > 1) takes the request from recv queue; >=20 > 2) waits for the respond from the secondary in hast_proto_recv_hdr() which > will never come because the secondary has not received the request and has > nothing to reply. If secondary is not going to reply, hast_proto_recv_hdr() should eventually timeout. On timeout, connection should be closed and this requests (and all the others) should be moved to done queue. It doesn't timeout at all or maybe the timeout is too long?=20 > So we have a request or several gotten stuck in in the recv queue. It loo= ks > like FS is waiting for the response on this request(s) sent by > ggate_send_thread() and gets stuck. >=20 > Below are logs for a similar example I made today: >=20 > The last messages before "outage": >=20 > Apr 23 14:10:20 hasta hastd: [storage] (primary) ggate_send: (0x28411c40)= Got request. > Apr 23 14:10:20 hasta hastd: [storage] (primary) ggate_send: (0x28411c40)= Moving request to the free queue. > Apr 23 14:10:20 hasta hastd: [storage] (primary) ggate_send: Taking reque= st. >=20 > During "outage": >=20 > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c80)= Request received from the kernel: WRITE(1925971968, 131072). > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c80)= Moving request to the send queues. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free = request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0)= Got free request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0)= Waiting for request from the kernel. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0)= Request received from the kernel: WRITE(1925348352, 1024). > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411cc0)= Moving request to the send queues. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free = request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00)= Got free request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00)= Waiting for request from the kernel. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00)= Request received from the kernel: WRITE(922860544, 1024). > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411c80)= Got request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411c80= ) Got request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411c80= ) Moving request to the recv queue. > Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: Taking requ= est. > Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411cc0= ) Got request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) remote_send: (0x28411cc0= ) Moving request to the recv queue. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411c00)= Moving request to the send queues. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free = request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0)= Got free request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0)= Waiting for request from the kernel. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0)= Request received from the kernel: WRITE(1926103040, 131072). > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411bc0)= Moving request to the send queues. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: Taking free = request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80)= Got free request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) ggate_recv: (0x28411b80)= Waiting for request from the kernel. > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking reque= st. > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411cc0)= Got request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking reque= st. > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411c00)= Got request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking reque= st. > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: (0x28411bc0)= Got request. > Apr 23 14:10:49 hasta hastd: [storage] (primary) local_send: Taking reque= st. >=20 > During "outage" two requests 0x28411c80 and 0x28411cc0 was received, > remote_send reported that it had succesfully sent the requests and moved = them > to recv queue. And the requests got stuck there IMHO hast_proto_recv_hdr() should timeout, but I don't change default timeout, which might be way too long. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --7mxbaLlpDEyR1+x6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvSnhcACgkQForvXbEpPzTFUwCgwflzhBfrmpHvFG3qogV/boc3 n4EAnRpciwMaxlokTftyxQ6YFBpPUWDb =r0Nr -----END PGP SIGNATURE----- --7mxbaLlpDEyR1+x6-- From owner-freebsd-fs@FreeBSD.ORG Sat Apr 24 11:33:58 2010 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 1EBAE106564A; Sat, 24 Apr 2010 11:33:58 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7188FC18; Sat, 24 Apr 2010 11:33:56 +0000 (UTC) Received: by bwz8 with SMTP id 8so10005592bwz.3 for ; Sat, 24 Apr 2010 04:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=S6PzMXZxIF3M7qQC/4IY8Dpc7k7aHinKTfSpvSGU87s=; b=DAdUozXg8sKzp+l3f6UApYlSrq/UZ4Lo/M9xvqlHugBMTpu42RzUVbBh5JJGCJO4dg 1w+Y3e67BJHStCaoHGeH46VByORT02hGRcebsnuJJ2+ng4IV5nS8FLkGu9uPqBV567Xf bW7THyhDPs/+50OUWNDHQqdeZIHesM6TzpNFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=CY9StfUyor97UWjBut/i8Kq+CbZ+d94i6I6uMnuE5nCYw2TkyjxO2lvJL/+r8SnZsg /hXiDIiNivH4gg2N8Uff3erlyK6ho9HLVZA0sQ3NyQ/ATEtkDsrw5j6HenKVis4ywa9V 6fxJlv1uRDYxj2ZQwvohFiqGwbkoIqFTuQ2JE= Received: by 10.204.84.220 with SMTP id k28mr832568bkl.70.1272108836187; Sat, 24 Apr 2010 04:33:56 -0700 (PDT) Received: from localhost ([95.69.167.160]) by mx.google.com with ESMTPS id 14sm812082bwz.10.2010.04.24.04.33.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Apr 2010 04:33:55 -0700 (PDT) To: Pawel Jakub Dawidek References: <86r5m9dvqf.fsf@zhuzha.ua1> <20100423062950.GD1670@garage.freebsd.pl> <86k4rye33e.fsf@zhuzha.ua1> <20100424073031.GD3067@garage.freebsd.pl> Organization: Home From: Mikolaj Golub Date: Sat, 24 Apr 2010 14:33:53 +0300 In-Reply-To: <20100424073031.GD3067@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Sat\, 24 Apr 2010 09\:30\:31 +0200") Message-ID: <868w8dgk4e.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs Subject: Re: HAST: primary might get stuck when there are connectivity problems with secondary 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, 24 Apr 2010 11:33:58 -0000 On Sat, 24 Apr 2010 09:30:31 +0200 Pawel Jakub Dawidek wrote: > If secondary is not going to reply, hast_proto_recv_hdr() should > eventually timeout. On timeout, connection should be closed and this > requests (and all the others) should be moved to done queue. > > It doesn't timeout at all or maybe the timeout is too long? After "outage" we have: on the primary: tcp4 0 0 172.20.66.201.57596 172.20.66.202.8457 ESTABLISHED tcp4 0 0 172.20.66.201.41841 172.20.66.202.8457 CLOSED on the secondary: tcp4 0 0 172.20.66.202.8457 172.20.66.201.57596 ESTABLISHED tcp4 0 0 172.20.66.202.8457 172.20.66.201.41841 ESTABLISHED So one of the connections (used by primary/remote_send_thread()) is broken (although the secondary is not aware about this, it it in the recv() at that time) and the second connection (used by primary/remote_recv_thread()) is alive. It does timeout after net.inet.tcp.keepidle (which is 2 hours by default) when the secondary starts to send keep alive packets. The secondary receive RST on its keep alive packet, recv() returns with error and the worker is restarted. As I wrote in my first letter the workaround is to set net.inet.tcp.keepidle to some small value on the secondary so it would notice a broken connection much earlier. >From the code I don't see how hast_proto_recv_hdr() may timeout if the connection is alive, have I missed something? -- Mikolaj Golub