From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 04:23:10 2008 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 A1AF4106567F for ; Sun, 2 Nov 2008 04:23:10 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9DCF38FC08 for ; Sun, 2 Nov 2008 04:23:09 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r55.edvax.de (port-92-196-106-204.dynamic.qsc.de [92.196.106.204]) by mx01.qsc.de (Postfix) with ESMTP id A5EE450B52 for ; Sun, 2 Nov 2008 05:06:03 +0100 (CET) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id mA2462AG011564 for ; Sun, 2 Nov 2008 05:06:02 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sun, 2 Nov 2008 05:06:01 +0100 From: Polytropon To: FreeBSD FS Message-Id: <20081102050601.9fccb80f.freebsd@edvax.de> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Repairing a defective UFS 2 partition with fsck_ffs (or other means) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2008 04:23:10 -0000 Dear list, I need your help in order to solve one of the strangest and most complicated problems existing in this universe. First of all I'd like to mention that I'm using FreeBSD nearly exclusively (along with Solaris and other UNIXes) for many years and I never had any problem similar to this. In fact, I never had *any* problem that required external help. But now, I'm lost. I don't know what to try, so I would be glad about any suggestion you could give me. I'm familiar with FreeBSD, shell scripting and C. My skills cover the usual "admin things". The accident that happended to me is some very stange thing, strange in regards of why the usual means of solving sich a problem don't seem to fit. In fact, I'm the second (!) person on earth who encountered this problem, as far as my investigations revealed. So I'm not sure if it's solvable at all. In order to explain what it's about, I'd like to follow this path: 1. What initially happened? (impact) 2. How does the problem occur? (examination) 3. What seems to be the reason? (diagnosis) 4. What did I try to solve the problem? (treatment) 5. What kind of solution should be possible? (prognosis) This should help to explain my problem properly. If there's more to know, please ask me. I'll try to answer as precisely as I can. And don't mind my bad English, it's not my native language. It's a long story, sorry. So here I'll go... 1. What initially happened? --------------------------- First of all, we're talking about this device: ad0: 114473MB at ata0-master UDMA100 The installation has been a FreeBSD 5.4-p something on a 2 GHz P4 machine with 768 MB SDR-SDRAM, working perfectly for many years now. The disk contained some partitions (ad0s1a as /, ad0s1d as /var, ad0s1e as /usr and ad0s1f as /home), formatted as UFS 2 with Soft Updates (except for /). While doing some web development (running: xterms with Midnight Commander and its editor, and Opera), the system suddenly stopped working, it froze. Some seconds later, it rebootet. The last message on VT 0 was something like this, if I remember correctly: cannot free some inode: already free automatic reboot When the system came up again, I relied on fsck_ffs solving all possible problems, as I knew it from the past. The result: Many defects in the file system contents, most of them didn't matter (can reinstall), but it wouldn't make the /home partition completely accessible again. I could copy the content from the archive and all the other users' home directories (luckily), but under no circumstances I could access my own (!) home directory again. HEART ATTACK!!! Of course, I didn't have a good backup (the last one was many years old). This is because I never encountered any problems, so I got lazy. Okay, that seems to be the revenge now. When you don't do your backups, something will happen. If you do your backups, nothing will happen, and you won't need them at all. That's their purpose. I'm sure you're familiar with this wisdom. :-) We're talking about documentation, mail archives, sources of programming and various projects here, data collections created in many years of hard work. So it's understandable why I want to get the stuff back as complete as possible, that would be great. 2. How does the problem occur? ------------------------------ The problem occured at system startup when running fsck_ffs. ** /dev/ad1s1f ** Last Mounted on /home ** Phase 1 - Check Blocks and Sizes 1035979 BAD I=259127 UNEXPECTED SOFT UPDATE INCONSISTENCY 1101472 DUP I=260035 UNEXPECTED SOFT UPDATE INCONSISTENCY [...] 1117681 DUP I=260039 UNEXPECTED SOFT UPDATE INCONSISTENCY 1117682 DUP I=260039 UNEXPECTED SOFT UPDATE INCONSISTENCY EXCESSIVE DUP BLKS I=260039 CONTINUE? yes [...] 3774433638169537379 BAD I=260051 UNEXPECTED SOFT UPDATE INCONSISTENCY 7021223365635213949 BAD I=260051 UNEXPECTED SOFT UPDATE INCONSISTENCY 8030898235988077411 BAD I=260051 UNEXPECTED SOFT UPDATE INCONSISTENCY 7310315658325879925 BAD I=260051 UNEXPECTED SOFT UPDATE INCONSISTENCY EXCESSIVE BAD BLKS I=260051 CONTINUE? yes [...] 1485568 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 1485569 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 1485570 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 1485571 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 1485572 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 1485573 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 1485574 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 1485575 DUP I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 5707022222514874728 BAD I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 8091332836184380774 BAD I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY 8598589197767749681 BAD I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY [...] 3631363939722683732 BAD I=290557 UNEXPECTED SOFT UPDATE INCONSISTENCY EXCESSIVE BAD BLKS I=290557 CONTINUE? yes INCORRECT BLOCK COUNT I=290557 (3104 should be 736) CORRECT? yes fsck_ffs: bad inode number 306176 to nextinode As it's obvious, fsck_ffs fails in phase 1. No recovery is done. In my opinion, this indicates a major defect of the file system. Maybe many defects, one worse than the other. If fsck_ffs can't repair it, it must be really bad. Okay, I took the opportunity to take a new hard disk where I already had installed FreeBSD 7. Why? Because other partitions had damages, too. On /dev/ad0s1a, /, nothing significant happened, but for example on /dev/ad0s1e, /usr, the whole X11R6/ subtree disappeared, and lost+found/ filled up with many directory fragments. So I could not use the system anymore. I put in the new disk as ad0 and the former ad0 disk as ad1 and retried the fsck_ffs check where fsck_ffs from version 5 failed with fsck_ffs from version 7. NB that no matter by which other name I called fsck_ffs, be it fsck_ufs or fsck_4.2bsd, the problem would stay the same. In order to do some tests, I made an 1:1 copy of the defective partition. This is a wise step, because I can't accidently damage important data, and when I messed up a copy, I can pull a new one. FreeBSD's dd program did the job well. It ran approx. 4 hours without any error message. The defect(s) of the disk partition are replicated 1:1 in the image. % cd ~/rescue % dd if=/dev/ad1s1f of=ad1s1f.dd bs=1m 86566+1 records in 86566+1 records out 90772014080 bytes transferred in 15156.804004 secs (5988862 bytes/sec) File size of ad1s1f.dd seemed to be good, the partition contained in this file was correctly recognized: % file ad1s1f.dd ad1s1f.dd: Unix Fast File system [v2] (little-endian) last mounted on /mnt, last written at Wed Jul 2 18:51:06 2008, clean flag 0, readonly flag 0, number of blocks 44322272, number of data blocks 42925108, number of cylinder groups 472, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization Of course, I tried to mount and access the partition's copy using the vnode mechanism for memory disks: % sudo mdconfig -a -t vnode -u 10 -f ad1s1f.dd % mount -o ro /dev/md10 mnt/ Fine, mount worked, so I could see what's on the disk. +<-/export/home/poly/rescue/mnt------v>+ | Name | Size | MTime | |/.. |UP--DIR| | |/.snap | 512|Dec 21 2004| |/archiv | 512|Feb 27 2006| |/backup | 512|Sep 23 2005| |/gast | 1024|Aug 25 2005| |/lost+found | 2048|Jul 1 10:15| |/markus | 512|Nov 20 2003| |/root | 1024|Apr 18 16:17| |/surf | 1024|Feb 17 2005| | .fsck_snapshot | 86567M|Jun 30 20:47| |?poly | 0|Jan 1 1970| <=== +--------------------------------------+ |/.. | +--------------------------------------+ poly@r55:~/rescue/mnt% [^] 1Help 2Menu 3View 4Edit 5Copy 6RenMov 7Mkdir 8Delete 9PullDn 10Quit Within the Midnight Commander, the name of the home directory has been marked with red color and a leading question mark. Do you recognize the timestamp? Strange. Furthermore, I could not change into this directory. % cd mnt/poly mnt/poly: Not a directory. % file mnt/poly mnt/poly: cannot open `mnt/poly' (Bad file descriptor) But I didn't give up hope yet. The data from within the home directory seemed to be present. The corresponding inodes don't seem to be marked as unused. I think this is what "orphan inodes" are called? Where do I take this idea from? There's an interesting match of the disk occupation percentage I found out when trying some df and dh examinations: % df -h Filesystem Size Used Avail Capacity Mounted on /dev/md10 82G 75G 716M 99% /export/home/poly/rescue/mnt At this point, a strange situation already occurs: The disk is 82 GB, 75 GB are used, but less than 1 GB is free. So there's something missing? I remember that at the point the disk got mad there were only approx. 700 MB free on /home. This matches the numbers above, But where's the rest? % sudo du -sch mnt du: mnt/poly: Bad file descriptor du: mnt/archiv/cr/clips.w32/s01.wmv: Bad file descriptor du: mnt/archiv/cr/clips.w32/s02.wmv: Bad file descriptor 52G mnt 52G total The disk is 82 GB, 75 GB are used, and the data structures that are still present make up 52 GB. So there must be approx. 20 GB somewhere. This could be the content of my home directory, the important data, my life, the universe, and everything. :-) Furthermore, you'll see two further "Bad file descriptor" warnings inside the archive directory. They don't matter, but they surely indicate that more than just the inode of my home directory died. So more problems can occur while proceeding. Of course, checking the partition's copy with dd, directly or via the md device, gives the same error message as already mentioned. There was a file /.fsck_snapshot of the partition's respective size. This file could be mounted, too, and within it there was a very old copy of my home directory. The snapshot has been taken at the time when I initially installed and configured this system, so it was very old, too old. 3. What seems to be the reason? ------------------------------- The reason seems to be that the inode describing my home directory doesn't exist anymore. This explains why its name is is still there (stored in the inode describing the root directory), but no further information about the file type (here: directory) and its respective content is available. But after all, this does not explain why fsck_ffs can't repair the partition any more, nor can any other program. Here my troubles understanding what happened start. 4. What did I try to solve the problem? --------------------------------------- As I already mentioned, FreeBSD's fsck_ffs is unable to repair the partition. fsck_ffs: bad inode number 306176 to nextinode Using FreeBSD's clri, I tried to clear the inodes that I thought would cause the problem of fsck_ffs: % sudo mdconfig -a -t vnode -u 10 -f ad1s1f.dd % clri 306176 /dev/md10 % sync This didn't work at all. I've tried other versions of fsck_ffs, too, running on my main machine or another one, from FreeBSD 5, 6 and 7. The only difference was a FreeBSD 5 system where fsck_ffs crashed within phase 1 with this message: fsck_ffs: cannot alloc 1073796864 bytes for inoinfo It seems that this particular machine didn't have enough RAM installed. And no matter if I checked the original partition or the copy I made with dd, the problem would always be the same. So then I tried an alternative to FreeBSD's dd, hoping that some "magical translation" would happen. My first choice was ddrescue from the ports: % ddrescue -d -r 3 -n /dev/ad1s1f ad1s1f.ddr logfile Press Ctrl-C to interrupt Initial status (read from logfile) rescued: 0 B, errsize: 0 B, errors: 0 Current status rescued: 90772 MB, errsize: 0 B, current rate: 6815 kB/s ipos: 90772 MB, errors: 0, average rate: 6723 kB/s opos: 90772 MB Finished The file ad1s1f.ddr was exactly the same as ad1s1f.dd, so no gain of hope here. Another idea was to copy data from the original disk using FreeBSD's fetch program - fetch -rR. Nope. Even FreeBSD's recoverdisk, done from the partition or its copy, just brought up another 1:1 copy including the problem. % recoverdisk ad1s1f.dd ad1s1f.rd start size block-len state done remaining % done 90771030016 984064 984064 0 90772014080 0 100.00000 Completed After this, I tried some "hardcore stuff": The Sleuth Kit from the ports, and first its dls program: % dls -v -f ufs -i raw ad1s1f.dd > ad1s1f.dls File system is corrupt (ffs_group_load: Group 12 descriptor offsets too large at 1129104) Allthough it didn't help me either, the error message is to be considered interesting: "Group 12 descriptor offsets too large at 1129104", but sadly, I don't know how to interpret this. Is 1129104 an inode? If yes: it's not allocated. What group is meant? Cylinder group? Maybe you could tell me. Another program from The Sleuth Kit, fls, allowed me to see some content of the partition. In fact, it even showed data that wasn't accessible, so it's within the range of the files that need to be restored. % fls -i raw -r ad1s1f.dd [...] d/- * 259072(realloc): poly + d/d * 3438592(realloc): 2003-05-17 [...] +++ d/d 5840896: brazil ++++ r/r 5840897: kate_bush_-_brazil.mp3 ++++ r/r 5840898: shangrila_towers.mp3 ++++ r/r 5840899: singing_telegram.mp3 ++++ r/r 5840900: the_first_noel.mp3 Segmentation fault (core dumped) So I checked: % fsdb -r ad1s1f.dd ad1s1f.dd is not a disk device CONTINUE? [yn] y ** ad1s1f.dd Editing file system `ad1s1f.dd' Last Mounted on /export/home/poly/rescue/mnt fsdb (inum: 2)> inode 3438592 current inode: directory I=3438592 MODE=40700 SIZE=512 BTIME=Nov 30 14:31:57 2007 [0 nsec] MTIME=Jun 26 05:06:14 2008 [0 nsec] CTIME=Jun 26 05:06:14 2008 [0 nsec] ATIME=Jul 1 21:13:05 2008 [0 nsec] OWNER=poly GRP=staff LINKCNT=2 FLAGS=0 BLKCNT=4 GEN=4803f917 fsdb (inum: 3438592)> ls slot 0 ino 3438592 reclen 12: directory, `.' slot 1 ino 447497 reclen 12: directory, `..' slot 2 ino 3438593 reclen 24: regular, `.sylpheed_mark' slot 3 ino 283193 reclen 12: regular, `1' slot 4 ino 289966 reclen 12: regular, `2' slot 5 ino 289970 reclen 12: regular, `3' slot 6 ino 3438620 reclen 24: regular, `.sylpheed_cache' slot 7 ino 290363 reclen 12: regular, `4' slot 8 ino 290366 reclen 12: regular, `5' slot 9 ino 290385 reclen 12: regular, `6' slot 10 ino 290444 reclen 368: regular, `7' fsdb (inum: 3438592)> inode 259072 current inode 259072: unallocated inode fsdb (inum: 259072)> quit ***** FILE SYSTEM STILL DIRTY ***** *** FILE SYSTEM MARKED DIRTY *** BE SURE TO RUN FSCK TO CLEAN UP ANY DAMAGE *** IF IT WAS MOUNTED, RE-MOUNT WITH -u -o reload Allthough the directory's name "2003-05-17" indicates that it should hold pictures from the cam/ subtree, it's content seems to be a Sylpheed MH mail directory. According to fls's output, inodes 3438592 and 259072 have been reallocated. And remember 259072? This has been my home directory, I think. Another program from the ports, scan_ffs, would only confirm what I already knew: % scan_ffs -lv /dev/md10 block 128 id 3f67c4e6,354efde8 size 44322272 block 160 id 3f67c4e6,354efde8 size 44322272 X: 177289088 0 4.2BSD 2048 16384 0 # /export/home/poly/rescue/mnt block 12032 id 616e732e,c0690070 size 44322272 block 12416 id 3f67c4e6,354efde8 size 44322272 block 13248 id 6e73746a,c3577600 size 44322272 block 376512 id 3f67c4e6,354efde8 size 44322272 block 752864 id 3f67c4e6,354efde8 size 44322272 block 1129216 id 3f67c4e6,354efde8 size 44322272 block 1505568 id 3f67c4e6,354efde8 size 44322272 [...] The 4.2BSD partition is still there and intact, okay. The program testdisk, as well available from the ports, seems to have the same purpose. But a lost partition is not the real problem, I think. Another approach I found would to be to avoid looking at the file system at all, instead trying to parse the disk "byte-wise" and look for magic bytes. A tool to do so is magicrescue from the ports. % magicrescue -r /usr/local/share/magicrescue/recipes -d mr_output /dev/md10 Read error on /dev/md10 at 102400 bytes: Invalid argument It didn't work on the memory disk, but fortunately on the dd copy: % magicrescue -r /usr/local/share/magicrescue/recipes -d mr_output ad1s1f.dd The files recovered by this program contained many different types, such as JPG images or MP3 files. Furthermore, files from within the inaccessible home directory had been restored. This is another hint that the data should still be there. But sadly, the file structures could not be retrieved, so I got lots of stuff into one directory. >From the manual of the program ffs2recov from the ports I found out that it's possible to create an inode where you can explicitely specify name and number. So I tried: % cd ~/rescue % ffs2recov -c 259072 -n poly ad1s1f.dd This caused a file called "poly" in the ~/rescue directory. Okay, not what I wanted to get. So I tried something really stupid: % cd ~/rescue % sudo mdconfig -a -t vnode -u 10 -f ad1s1f.dd % mount -o rw /dev/md10 mnt/ % cd mnt % ffs2recov -c 259072 -n poly ad1s1f.dd % sync panic: ffs_write: type 0xc5d37e04 0 (0,16384) Dumping 136 MB: 121 105 89 73 57 41 (CTRL-C to abort) 25 9 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... [...] ad0: 305245MB at ata0-master UDMA100 ad1: 305245MB at ata0-slave UDMA100 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: FAILURE - READ_DMA status=51 error=84 LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: FAILURE - READ_DMA status=51 error=84 LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64 ad1: FAILURE - READ_DMA status=51 error=84 LBA=64 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: FAILURE - READ_DMA status=51 error=84 LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: FAILURE - READ_DMA status=51 error=84 LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: FAILURE - READ_DMA status=51 error=84 LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad1: FAILURE - READ_DMA status=51 error=84 LBA=0 savecore: reboot after panic: ffs_write: type 0xc5d37e04 0 (0,16384) You can imagine my heartbeat going up to 200 at this moment! :-) Fortunately, no data was lost. I've got no idea what happened, but I'm sure my approach was wrong. The system would not react in this way without a proper reason. And NB that the ad0 and ad1 you see are completely different things, the original 120 GB Seagate disk is on the shelf. This is the new FreeBSD 7 system is put on ad0, and ad1 is reserved for backup purposes. Why does it complain that much? Okay, don't mind, it's not important now. 5. What kind of solution should be possible? -------------------------------------------- In general, there would be two options: a) Modify fsck_ffs so it will work. b) Modify the file system so fsck_ffs will work. Of course, I've got no good clue how to do this in particular. Let me first describe what I did to fsck_ffs. I first took a look at fsck_ffs's source code. Well... it's not that I did understand very much of it, sadly, but I could find the position where the error fsck_ffs: bad inode number 306176 to nextinode came from: it was /usr/src/sbin/fsck_ffs/inode.c line 319: if (inumber != nextino++ || inumber > lastvalidinum) errx(EEXIT, "bad inode number %d to nextinode", inumber); Oh how I love disjunctions in exit conditions! :-) So I made a change to this part, just to see what would happen. (And: Yes, I know, "trial & error" is not a programming concept.) I used a copy of the subtrees sbin/fsck_ffs/ + sbin/mount/ and sys/ufs/ffs/ + sys/ufs/ufs/ from /usr/src/, then issued the command "make" from within ~/rescue/sbin/fsck_ffs/, which would give me an executable fsck_ffs in this directory. I copied it to ~/rescue and tested it with the 1:1 dd copy. if(inumber != nextino++) { printf("--- condition: inumber != nextino++\n"); printf("--- inumber=%d nextino(++)=%d lastinum=%d\n", inumber, nextino, lastinum); errx(EEXIT, "bad inode number %d to nextinode", inumber); } if(inumber > lastvalidinum) { printf("--- condition: inumber > lastvalidinum\n"); printf("--- inumber=%d lastvalidinum=%d, lastinum=%d\n", inumber, lastvalidinum, lastinum); errx(EEXIT, "bad inode number %d to nextinode", inumber); } This was the result: % ./fsck_ffs -yf ad1s1f.dd [...] --- condition: inumber > lastvalidinum --- inumber=306176 lastvalidinum=306175, lastinum=306176 fsck_ffs: bad inode number 306176 to nextinode So what's up with inode 306176? When invoking fsdb on this inode, I could see the content of a directory, and ils from The Sleuth Kit revealed that it seems to be a directory within the inaccessible home directory. slot 150 ino 306176 reclen 20: directory, `hellraiser' slot 1566 ino 306176 reclen 12: directory, `.' Strange, isn't it? Finally, I decided to comment out the whole part. I found fsck_ffs complaining in fsutil.c line 139: if (inum > maxino) errx(EEXIT, "inoinfo: inumber %d out of range", inum); So I put in another "checkpoint" there: printf("---> %d\n", inum); if (inum > maxino) { printf("--- condition: inum > maxino\n"); printf("--- inum=%d maxino=%d\n", inum, maxino); errx(EEXIT, "inoinfo: inumber %d out of range", inum); } The result was this: % ./fsck_ffs -yf ad1s1f.dd [...] THE FOLLOWING DISK SECTORS COULD NOT BE READ: 177638368, 177638369, 177638370, 177638371, 177638372, 177638373, 177638374, 177638375, 177638376, 177638377, 177638378, 177638379, 177638380, 177638381, 177638382, 177638383, 177638384, 177638385, 177638386, 177638387, 177638388, 177638389, 177638390, 177638391, 177638392, 177638393, 177638394, 177638395, 177638396, 177638397, 177638398, 177638399, 177638400, 177638401, 177638402, 177638403, 177638404, 177638405, 177638406, 177638407, 177638408, 177638409, 177638410, 177638411, 177638412, 177638413, 177638414, 177638415, 177638416, 177638417, 177638418, 177638419, 177638420, 177638421, 177638422, 177638423, 177638424, 177638425, 177638426, 177638427, 177638428, 177638429, 177638430, 177638431, 177638432, 177638433, 177638434, 177638435, 177638436, 177638437, 177638438, 177638439, 177638440, 177638441, 177638442, 177638443, 177638444, 177638445, 177638446, 177638447, 177638448, 177638449, 177638450, 177638451, 177638452, 177638453, 177638454, 177638455, 177638456, 177638457, 177638458, 177638459, 177638460, 177638461, 177638462, 177638463, 177638464, 177638465, 177638466, 177638467, 177638468, 177638469, 177638470, 177638471, 177638472, 177638473, 177638474, 177638475, 177638476, 177638477, 177638478, 177638479, 177638480, 177638481, 177638482, 177638483, 177638484, 177638485, 177638486, 177638487, 177638488, 177638489, 177638490, 177638491, 177638492, 177638493, 177638494, 177638495, --- condition: inum > maxino --- inum=11116545 maxino=11116544 fsck_ffs: inoinfo: inumber 11116545 out of range Seemed to be an important condition. :-) So what's this again? The answer was in setup.c line 209: maxino = sblock.fs_ncg * sblock.fs_ipg; Is there some information retrieved incorrectly from the file system's superblock causing all the trouble? Well, I did try checks with fsck_ffs with refering to alternate superblocks, but no luck. Or does it mean that there are 11116544 inodes on the partition? This would imply that (not mentioning directories) 11 millions of files can be created - or are stored on this disk totally? At this point, I decided to give up this way of "fixing"; most of the conditions seem to be well intended, the defect on the disk must be that bad that fsck_ffs can't handle it anymore. And now for the file system. As it is already clear, the inode of the home directory is gone. So an idea would be to create a new inode, with the same name and number as it should be. Good idea? No, obviously not. I tried it in two different ways, with no luck. So that seems to be insufficient. I do understand it: The inode number created would only be a kind of "link entry" inside the root directory which points to further information. But where should the new home directory entry know about its content? >From the friendly FreeBSD questions mailing list I even learned that there's no way to predict the inode numbers. If I assume a directory D with its inode number i(D), within D a file F with its inode number i(F), I can't claim i(D) < i(F), so I can't expect any special inode number. I think there's more to establish an intact directory structure, not just a simple "make inode with name". The directory needs to be populated correctly, but therefore, I would need to know which files are inside it. So it would be neccessary to pick all possible inode numbers and look what's behind them. This means I would need to "walk back" the .. paths to see which one finally leads to the home directory, and then put the 1st instance directory name (or inode number instead of the name, because the name is lost) into one of the directory slots; do I call them correctly? As far as I've already learned, when "walking back" the path from a file deep within a directory structure, every inode contains a field "where it comes from", let's say, where CWD and .. are (as an inode number). Let's assume we're at the inode 259301 refering to a file bla.txt. Then something like this structure should exist: bla.txt dingens/ foo/ poly/ / 259301 -----> 259285 -----> 259140 -----> 259072 -----> 2 This would be /home/poly/foo/dingens/bla.txt on ad0s1f (where / is then mounted as /home). When I can assume that every inode still knows "where it came from", what would be a useful tool to build poly/ (12345) again? I think I'll need to construct its content again, because just by creating poly/ as 12345, where does the filesystem know from what's the content of poly/? Is the term "directory slots" I came across related to that topic? Which sources could give good hints? For any considerations, I'll assume that only the inode of my home directory is gone. I can't tell for sure that it will be this way, it's possible that other inodes have died, too. I can't assert it won't be the case. In general, I think what's needed is a way to reconnect the "orphan" inodes to "normal" inodes again so they can be accessed. Because the home directory's inode is gone, any information about the files and directories on its 1st level is gone, too. So these would not be restored with their original names, but with the inode number as names, just like fsck_ffs would do it with its lost+found/ mechanism. All data within the directories from the 1st level would of course still have their names because these inodes are present. I'm thinking about something like this: Formerly: / poly/ foo/ bar.c baz/ boing/ boo.h boom.h bla.c .xchat/ xchat.conf .fetchmailrc After restore: / poly/ #123456/ bar.c #123789/ boing/ boo.h boom.h #124785 #127854/ xchat.conf #128745 ^^^^^^^ There are tools that can help to "restore" the 1st level, for example FreeBSD's file command. There aren't many files where a problem should occur: File names can usually be recognized from the data they contain (source, note, configuration file etc.), and directories can be recognized by the names of the files they contain. Of course, that's the thing that would happen if fsck_ffs would work as initially intended. When I see it, I will remember what the correct names were. So these were my first thoughts about this problem. I hope you can help me with some ideas, concepts or suggestions, or documents or source files worth studying. I don't expect you to solve my problem, I'm not greedy. :-) -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 07:20:21 2008 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 093E9106568A for ; Sun, 2 Nov 2008 07:20:21 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id BF8A08FC19 for ; Sun, 2 Nov 2008 07:20:20 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r55.edvax.de (port-92-196-106-204.dynamic.qsc.de [92.196.106.204]) by mx01.qsc.de (Postfix) with ESMTP id 1D1E050927; Sun, 2 Nov 2008 08:20:17 +0100 (CET) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id mA27KH50001844; Sun, 2 Nov 2008 08:20:17 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sun, 2 Nov 2008 08:20:15 +0100 From: Polytropon To: frank@exit.com Message-Id: <20081102082015.b8d40d77.freebsd@edvax.de> In-Reply-To: <1225600923.97152.3.camel@jill.exit.com> References: <20081102050601.9fccb80f.freebsd@edvax.de> <1225600923.97152.3.camel@jill.exit.com> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD FS Subject: Re: Repairing a defective UFS 2 partition with fsck_ffs (or other means) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2008 07:20:21 -0000 Hi, many thanks for your quick reply. On Sat, 01 Nov 2008 21:42:03 -0700, Frank Mayhar wrote: > Check out /usr/ports/sysutils/ffs2recov. It won't repair the filesystem > but it may be able to recover some or all of your data. I've already tried this program: % mdconfig -a -t vnode -f ad1s1f.dd md0 % ffs2recov -dav /dev/md0 will create many files according to inode numbers. The file command will identify them as "data", and they are all of the same size, group-wise. I don't know what I could do with these files. Furthermore, these errors are repeatedly displayed: getinode: inode size (14199049117881519608 > 175821242368) too big, skipping. and main.c:529 memory allocation failed for inode 294970, -1693177856 with different values. I'm not sure if ffs2recov is the right tool here, or am I using it the wrong way? I've read /usr/local/share/doc/sleuthkit/ref_fs.txt carefully, but it doesn't seem to help me either. I don't want to buy expensive "Windows" software that I have to run in wine (along with the usual problems upcoming) for something that I think could be solved using FreeBSD's on-board means, or even send the disk to a recovery company for much money. I simply can't afford this. If you have any experiences regarding this special case of data recovery, please give me an advice where I should play attention. -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 15:09:26 2008 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 2DD451065673; Sun, 2 Nov 2008 15:09:26 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id E1F888FC0C; Sun, 2 Nov 2008 15:09:25 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 99A2023C424; Sun, 2 Nov 2008 16:09:24 +0100 (CET) Date: Sun, 2 Nov 2008 16:09:24 +0100 From: Peter Schuller To: Andrew Snow Message-ID: <20081102150924.GB59552@hyperion.scode.org> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8D23.6030309@modulus.org> 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: <490A8D23.6030309@modulus.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-fs@freebsd.org, Jeremy Chadwick Subject: Re: Areca vs. ZFS performance testing. 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, 02 Nov 2008 15:09:26 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Its probably worth playing with vfs.zfs.cache_flush_disable when using=20 > the hardware RAID. >=20 > By default, ZFS will flush the entire hardware cache just to make sure=20 > the ZFS Intent Log (ZIL) has been written. >=20 > This isn't so bad on a group of hard disks with small caches, but bad if= =20 > you have 256mb of controller write cache. Flushing the cache to constituent drives also has a direct impact on latency, even without any dirty data (save what you just written) in the cache. If you're doing anything that does frequent fsync():s, you're likely to not want to wait for actual persistence to disk (with battery backed cache). In any case, why would the actual RAID controller cache be flushed, unless someone expliclitly configured it such? I would expect a regular BIO_FLUSH (that's all ZFS is going right?) to be satisfied by the data being contained in the controller cache, under the assumption that it is battery backed, and that the storage volume/controller has not been explicitly configured otherwise to not rely on the battery for persistence. Please correct me if I'm wrong, but if synchronous writing to your RAID device results in actually waiting for underlying disks to commit the data to platters, that sounds like a driver/controller problem/policy issue rather than anything that should be fixed by tweaking ZFS. Or is it the case that ZFS does both a "regular" request to commit data (which I thought was the purpose of BIO_FLUSH, even though the "FLUSH" sounds more specific) and separately does a "flush any actual caches no matter what" type of request that ends up bypassing controller policy (because it is needed on stupid SATA drives or such)? --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkNwqQACgkQDNor2+l1i30+tQCfYKIGEHETqNg1gfwi9XwBuFuq dMAAoK7OczyR6rVe6gigw+EG797v0L2I =5oRU -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 16:17:21 2008 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 B2FE5106568D; Sun, 2 Nov 2008 16:17:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id E2DBF8FC26; Sun, 2 Nov 2008 16:17:20 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1729054fgb.35 for ; Sun, 02 Nov 2008 08:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=tRR41TuxcmwWr1fcdySQEGfSm/5CQFtJbjUdzVtpAPg=; b=dXULrz6xkB50Z9hJU94kOB63yA18mTCuKRHVHZ7QXPqfxFQNKzr1gAxDCQsKDvaNdZ ng4bVlkBUs4ifXgmPu1+CXxYYQK9Ca/zmLlXXreC4l3nghI6fhU2/zSvhzoBXeaB0mEv k23MHGpnALbifNuzF8KBK6SOt9Bu1u6WTjuuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=plix37eFrJOyuKwTjC+ajo1VL2acsGo57sVFNiijDgxf0e+uygqQEaM0qodm62nISR irlcH291as9iVUEmdLCRjlM5oi6GKf12QCRTwIkSsHgSoINoMgoucUQNhAS6+N7jxHW2 c78qxoL1+RWH++xwZX1cBA3f53ye3QS6hVikQ= Received: by 10.86.66.19 with SMTP id o19mr10091634fga.64.1225642638896; Sun, 02 Nov 2008 08:17:18 -0800 (PST) Received: by 10.86.78.14 with HTTP; Sun, 2 Nov 2008 08:17:18 -0800 (PST) Message-ID: <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> Date: Sun, 2 Nov 2008 17:17:18 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Yuri Pankov" In-Reply-To: <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> X-Google-Sender-Auth: b35bc9f364f79055 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 02 Nov 2008 16:17:21 -0000 2008/11/2, Attilio Rao : > 2008/11/2, Yuri Pankov : > > > Hi, > > > > Trying to mount nonexistent smb share with mount_smbfs leads to > > following panic: > > > > # mount_smbfs //yuri@lifebane/blahblah /mnt > > > > Unread portion of the kernel message buffer: > > smb_co_lock: recursive lock for object 1 > > panic: Lock (lockmgr) smb_vc not locked @ > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329. > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > panic() at panic+0x182 > > witness_assert() at witness_assert+0x21a > > __lockmgr_args() at __lockmgr_args+0x17a > > smb_co_put() at smb_co_put+0x76 > > smb_sm_lookup() at smb_sm_lookup+0xfe > > smb_usr_lookup() at smb_usr_lookup+0xcd > > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > > giant_ioctl() at giant_ioctl+0x75 > > devfs_ioctl_f() at devfs_ioctl_f+0x76 > > kern_ioctl() at kern_ioctl+0x92 > > ioctl() at ioctl+0xfd > > syscall() at syscall+0x1bf > > Xfast_syscall() at Xfast_syscall+0xab > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > 0x7fffffffe038, rbp = 0x7fffffffe450 --- > > Uptime: 6m46s > > Physical memory: 2032 MB > > > So, what is happening here is that smb_co_lock() is AFU. > Infact looking at the code: > int > smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td) > { > ... > if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && > (flags & LK_CANRECURSE) == 0) { > SMBERROR("recursive lock for object %d\n", cp->co_level); > return 0; > } > ... Yuri, could you please test this fix: http://www.freebsd.org/~attilio/netsmb.diff and report if it works? You could get a KASSERT running but this is expected as I want to identify on the callers who passes a malformed request and fix it. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 16:10:35 2008 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 4FC4A1065676 for ; Sun, 2 Nov 2008 16:10:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 2219B8FC1F for ; Sun, 2 Nov 2008 16:10:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so2134524mue.3 for ; Sun, 02 Nov 2008 08:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=LT5dNGkZQ+4MP582TSUWXiFjMZWtCaSCeuIj4a+Irc0=; b=ohTTz9L40DoVQ4rLLZy/09zUEd2h2NZIwtX5FikT683JJlWd9H6gaDFetP7KQbESyS v/o8a5+Qa9gRNcZof4uWymkGQGqKyB5Yw4KTsXdvWBlOaHaRpPA/25Qt4ZiOEt4EAW5F IlE1tUwHWXrAWQfs/Y3pzk3n54OGWlYVDS6rQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=DRoLWXO+jS1g7d3bEPD2Oz/VySMnckfJJs7xdjlDoW/46vXi24jcESYDFIS5ww3uAX HBXtClziY6vDO+ECM7TkGFcvV+eAde2FN7Eu8Ka6ctG3DhEQheylX5Ddh5PPt64Cll5u rZ50xoGX9UYo3cOET8gaGa60kA8ObE0zdTJ6I= Received: by 10.103.22.16 with SMTP id z16mr4275515mui.78.1225640244103; Sun, 02 Nov 2008 07:37:24 -0800 (PST) Received: by 10.103.239.14 with HTTP; Sun, 2 Nov 2008 07:37:24 -0800 (PST) Message-ID: <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> Date: Sun, 2 Nov 2008 16:37:24 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Yuri Pankov" In-Reply-To: <20081102123100.GA1434@darklight.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> X-Google-Sender-Auth: 47038d8779c02b0d X-Mailman-Approved-At: Sun, 02 Nov 2008 16:42:46 +0000 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 02 Nov 2008 16:10:35 -0000 2008/11/2, Yuri Pankov : > Hi, > > Trying to mount nonexistent smb share with mount_smbfs leads to > following panic: > > # mount_smbfs //yuri@lifebane/blahblah /mnt > > Unread portion of the kernel message buffer: > smb_co_lock: recursive lock for object 1 > panic: Lock (lockmgr) smb_vc not locked @ > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329. > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > witness_assert() at witness_assert+0x21a > __lockmgr_args() at __lockmgr_args+0x17a > smb_co_put() at smb_co_put+0x76 > smb_sm_lookup() at smb_sm_lookup+0xfe > smb_usr_lookup() at smb_usr_lookup+0xcd > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > giant_ioctl() at giant_ioctl+0x75 > devfs_ioctl_f() at devfs_ioctl_f+0x76 > kern_ioctl() at kern_ioctl+0x92 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1bf > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > 0x7fffffffe038, rbp = 0x7fffffffe450 --- > Uptime: 6m46s > Physical memory: 2032 MB So, what is happening here is that smb_co_lock() is AFU. Infact looking at the code: int smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td) { ... if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && (flags & LK_CANRECURSE) == 0) { SMBERROR("recursive lock for object %d\n", cp->co_level); return 0; } ... from that it is obvious that smb_co_lock() won't recurse the lock really, but will let believe the consumer it acquired the lock successfully without panicking at all (the printf is like a little joke there). I think that we don't panic here mainly because these are "user driver" events and we want avoid to get a DoS for the kernel but it is an unacceptable code also. This can be fixed by allowing recuring lockmgr by default but the problem is more vaste. For example, it would be very nice to drop the LK_DRAIN support from netsmb in order to completely remove it from the 8.0 kernel serie and kill a bogus / dangerous option for lockmgr. It would be a cornerstone for lockmgr wealth really. What really is missing here is a valid netsmb maintainer, someone that knows well the layers involved, is motivated to work on it and can take advantage from the other kernel developer experience on the most hardcore parts. It would be also nice, for example, to bring in some Apple's changes (like the crypto support). Someone willing to step in would be very appreciated. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 17:01:31 2008 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 199B81065670 for ; Sun, 2 Nov 2008 17:01:31 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8D98FC08 for ; Sun, 2 Nov 2008 17:01:30 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so669156eyi.7 for ; Sun, 02 Nov 2008 09:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=mEWkKJ+xT6SaSwxwFmAFVQXYON1G240N6q3FCSrZxjQ=; b=vn1xBsnFqfLj9sWahXdJCdabqhfHfq/i/c1ssVlE26LYlEJNujzSOOeh+gHNDi6/8C SKSsf3N5scRyTrFXJEHuxRKnCGl8fDG/bex+NDGlPTd1TL2vl4NNxJE0Hct2na4O44mY gfcqQEdV0Fa7RM4y17OAQq6HFvUhh9d5Np2DQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=RXgCAvk0cVZkFPprwFcpC0fBBQ/6gk/OMAiokJ8TnHTgQ6XiFuPNMFrKNUhkWrQuPe B6u0wlMhB6pywdHdKHbV1W0cAHmiCVPJgu57udcwKPcp5gELxCxGkO/P7193wxC/sb0d sj/F15zuzewHCrvfqL5OCZF3/Flc+SqmgcXNQ= Received: by 10.210.127.13 with SMTP id z13mr7413463ebc.11.1225643591692; Sun, 02 Nov 2008 08:33:11 -0800 (PST) Received: from darklight.homeunix.org ([85.175.24.53]) by mx.google.com with ESMTPS id g9sm11790271gvc.0.2008.11.02.08.33.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Nov 2008 08:33:11 -0800 (PST) Received: from darklight.homeunix.org (yuri@darklight.homeunix.org [127.0.0.1]) by darklight.homeunix.org (8.14.3/8.14.3) with ESMTP id mA2GX7v2071530; Sun, 2 Nov 2008 19:33:07 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.homeunix.org (8.14.3/8.14.3/Submit) id mA2GX7S1071529; Sun, 2 Nov 2008 19:33:07 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.homeunix.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Sun, 2 Nov 2008 19:33:07 +0300 From: Yuri Pankov To: Attilio Rao Message-ID: <20081102163307.GB1434@darklight.homeunix.org> References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 02 Nov 2008 17:01:31 -0000 On Sun, Nov 02, 2008 at 05:17:18PM +0100, Attilio Rao wrote: > 2008/11/2, Attilio Rao : > > 2008/11/2, Yuri Pankov : > > > > > Hi, > > > > > > Trying to mount nonexistent smb share with mount_smbfs leads to > > > following panic: > > > > > > # mount_smbfs //yuri@lifebane/blahblah /mnt > > > > > > Unread portion of the kernel message buffer: > > > smb_co_lock: recursive lock for object 1 > > > panic: Lock (lockmgr) smb_vc not locked @ > > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329. > > > cpuid = 0 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > panic() at panic+0x182 > > > witness_assert() at witness_assert+0x21a > > > __lockmgr_args() at __lockmgr_args+0x17a > > > smb_co_put() at smb_co_put+0x76 > > > smb_sm_lookup() at smb_sm_lookup+0xfe > > > smb_usr_lookup() at smb_usr_lookup+0xcd > > > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > > > giant_ioctl() at giant_ioctl+0x75 > > > devfs_ioctl_f() at devfs_ioctl_f+0x76 > > > kern_ioctl() at kern_ioctl+0x92 > > > ioctl() at ioctl+0xfd > > > syscall() at syscall+0x1bf > > > Xfast_syscall() at Xfast_syscall+0xab > > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > > 0x7fffffffe038, rbp = 0x7fffffffe450 --- > > > Uptime: 6m46s > > > Physical memory: 2032 MB > > > > > > So, what is happening here is that smb_co_lock() is AFU. > > Infact looking at the code: > > int > > smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td) > > { > > ... > > if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && > > (flags & LK_CANRECURSE) == 0) { > > SMBERROR("recursive lock for object %d\n", cp->co_level); > > return 0; > > } > > ... > > Yuri, > could you please test this fix: > http://www.freebsd.org/~attilio/netsmb.diff > > and report if it works? > You could get a KASSERT running but this is expected as I want to > identify on the callers who passes a malformed request and fix it. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein Thanks, Attilio. With this patch system doesn't panic anymore with nonexistent share names (though I had to comment out smb_co_lockstatus prototype and function to get rid of -Werror complaints). Still getting a LOR: netsmb_dev: loaded lock order reversal: 1st 0xffffff0021644008 smb_vc (smb_vc) @ /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:332 2nd 0xffffffff81037368 smbsm (smbsm) @ /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:348 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xc2a smb_co_lock() at smb_co_lock+0x38 smb_co_gone() at smb_co_gone+0x38 smb_sm_lookup() at smb_sm_lookup+0xfe smb_usr_lookup() at smb_usr_lookup+0xcd nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 giant_ioctl() at giant_ioctl+0x75 devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0x92 ioctl() at ioctl+0xfd syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = 0x7fffffffe048, rbp = 0x7fffffffe460 --- Thanks, Yuri From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 17:39:18 2008 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 02583106567A for ; Sun, 2 Nov 2008 17:39:18 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6018FC24 for ; Sun, 2 Nov 2008 17:39:17 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r55.edvax.de (port-92-196-106-204.dynamic.qsc.de [92.196.106.204]) by mx01.qsc.de (Postfix) with ESMTP id 2B83050C6B; Sun, 2 Nov 2008 18:39:14 +0100 (CET) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id mA2HdDrH001561; Sun, 2 Nov 2008 18:39:13 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sun, 2 Nov 2008 18:39:13 +0100 From: Polytropon To: frank@exit.com Message-Id: <20081102183913.d4ec58f6.freebsd@edvax.de> In-Reply-To: <1225642408.97152.15.camel@jill.exit.com> References: <20081102050601.9fccb80f.freebsd@edvax.de> <1225600923.97152.3.camel@jill.exit.com> <20081102082015.b8d40d77.freebsd@edvax.de> <1225642408.97152.15.camel@jill.exit.com> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD FS Subject: Re: Repairing a defective UFS 2 partition with fsck_ffs (or other means) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2008 17:39:18 -0000 On Sun, 02 Nov 2008 08:13:28 -0800, Frank Mayhar wrote: > ffs2recov is a very low-level tool to recover files and data from a > corrupted file system. Among other things, it can search for > directories, print contents of inodes, recover files by name and recover > directory hierarchies given an inode and a name. This is something I must have misunderstood from the manual. As I mentioned before, English is not my native language. So it's possible that this part of the examples section If you would like to recover inode 2385 named dir and all it's decendants the command: % ffs2recov -c 2385 -n dir ffs.image will create dir, populate it, setting modes, permissions, and times to the originals. will not "recreate the inode", but will take this as a starting point to recover the rest... I'll investigate this further. > It's not for the faint > of heart but it can recover data that nothing else can. Up to this point, I agree that ffs2recov seems to be the most promising tool. But you're right, I have to learn more about this topic. It isn't that easy as creating a FAT with a hex editor. :-) > It sounds like your home directory inode has been trashed, in which case > your only choice is to try to find the directory blocks themselves, dump > them and use them to find the names of the files in that directory. > Otherwise you'll be stuck with them named by their inode. Thank you, this is a very good approach. I found ffs2recov very handy for the different stages, such as dumping blocks, retrieving inode informations and such things. > Those errors mean that there is very serious corruption on disk. I do believe it's so. Allthough I'm not sure what particularly caused the damage, according to fsck_ffs there seem to be many corruptions within the soft update data and the inodes, which form some kind of linked list, as far as I understood it. > The > program is ignoring those errors and forging on to try to find and > recover everything it can. It may be that you won't be able to recover > much. Depends on the "magnitude of damage"... which I can't tell exactly of. > You should, however, be able to recover at least some of your > data, especially the stuff that's further away (physically and > logically) from the trashed area of the disk. I need to try some more, and I think the ref_fs.txt from The Sleuth Kit mentioned in my first posting will give some good information about how files and directories, inodes, blocks and the other termini technici build up the basic principles of an UFS file system. It's... I never had much interest in how it worked, as long as it worked, but I found out that many knowledge is obtained when trying to solve some strange problem. After some time, you can explain how TCP/IP, routing or compilation processes work. :-) > I really can't hold your hand, here, since I'm overloaded as it is, > sorry. Best of luck. Thank you. You did really help me giving some advices. And after all... all the data loss and damages... I find the topic quite interesting. Allthough there's no high demand for this data, I'll take the time to learn more, and maybe find a way to solve the problem using ffs2recov. There's probably no need to reinvent the wheel until you learn how to drive. :-) /* PS. I'm not on the -fs mailing list. */ -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 17:53:29 2008 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 438FC1065693; Sun, 2 Nov 2008 17:53:29 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 3F47E8FC1F; Sun, 2 Nov 2008 17:53:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1757078fgb.35 for ; Sun, 02 Nov 2008 09:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=7XyW/KnpcXkLJ0hL7US7oXjKvf5F9PDjfzskb0rbiYQ=; b=AMRFkcTRrYt/IO90t5p/JXyq6SoET57EbUYzKzdK3TZhM+xswCLg36j1trmjlc/ZmA D1nPxVYuAxl5UL7CcWMHR3BdN+LeJzMWiq0reZ0eoz619afzNObewT5zCeCA/QY+T34K ls2kmW5k5w47vlTZqNXH81uPTgsWOUYEC9dB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=xrLhQ2LWnk3TATlKDLbbxq5WslZTx/LgdSBnu0Rdgz1SAPgUKgEmQwLJ/MyU7Lw/qv x+w9xgK+4EpT5iV/YTvwq8FP3ZOBQJWL9JjaWu/REOXNMdVhBdnqHx73Piukn6x2xrWn T0nxNJ+DiT1VlRtk0NnwsNZu/D59sVBVbrMqQ= Received: by 10.86.66.19 with SMTP id o19mr10178116fga.18.1225648405145; Sun, 02 Nov 2008 09:53:25 -0800 (PST) Received: by 10.86.78.14 with HTTP; Sun, 2 Nov 2008 09:53:25 -0800 (PST) Message-ID: <3bbf2fe10811020953l29f1a7eesa4f4eeb49f0a2eba@mail.gmail.com> Date: Sun, 2 Nov 2008 18:53:25 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Yuri Pankov" In-Reply-To: <20081102163307.GB1434@darklight.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <20081102163307.GB1434@darklight.homeunix.org> X-Google-Sender-Auth: 5dc9fe2f9ed1fc7a Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 02 Nov 2008 17:53:29 -0000 2008/11/2, Yuri Pankov : > On Sun, Nov 02, 2008 at 05:17:18PM +0100, Attilio Rao wrote: > > 2008/11/2, Attilio Rao : > > > 2008/11/2, Yuri Pankov : > > > > > > > Hi, > > > > > > > > Trying to mount nonexistent smb share with mount_smbfs leads to > > > > following panic: > > > > > > > > # mount_smbfs //yuri@lifebane/blahblah /mnt > > > > > > > > Unread portion of the kernel message buffer: > > > > smb_co_lock: recursive lock for object 1 > > > > panic: Lock (lockmgr) smb_vc not locked @ > > > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329. > > > > cpuid = 0 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > panic() at panic+0x182 > > > > witness_assert() at witness_assert+0x21a > > > > __lockmgr_args() at __lockmgr_args+0x17a > > > > smb_co_put() at smb_co_put+0x76 > > > > smb_sm_lookup() at smb_sm_lookup+0xfe > > > > smb_usr_lookup() at smb_usr_lookup+0xcd > > > > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > > > > giant_ioctl() at giant_ioctl+0x75 > > > > devfs_ioctl_f() at devfs_ioctl_f+0x76 > > > > kern_ioctl() at kern_ioctl+0x92 > > > > ioctl() at ioctl+0xfd > > > > syscall() at syscall+0x1bf > > > > Xfast_syscall() at Xfast_syscall+0xab > > > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > > > 0x7fffffffe038, rbp = 0x7fffffffe450 --- > > > > Uptime: 6m46s > > > > Physical memory: 2032 MB > > > > > > > > > So, what is happening here is that smb_co_lock() is AFU. > > > Infact looking at the code: > > > int > > > smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td) > > > { > > > ... > > > if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && > > > (flags & LK_CANRECURSE) == 0) { > > > SMBERROR("recursive lock for object %d\n", cp->co_level); > > > return 0; > > > } > > > ... > > > > Yuri, > > could you please test this fix: > > http://www.freebsd.org/~attilio/netsmb.diff > > > > and report if it works? > > You could get a KASSERT running but this is expected as I want to > > identify on the callers who passes a malformed request and fix it. > > > > Thanks, > > Attilio > > > > > > -- > > Peace can only be achieved by understanding - A. Einstein > > > Thanks, Attilio. > > With this patch system doesn't panic anymore with nonexistent share > names (though I had to comment out smb_co_lockstatus prototype and > function to get rid of -Werror complaints). Still getting a LOR: > > netsmb_dev: loaded > lock order reversal: > 1st 0xffffff0021644008 smb_vc (smb_vc) @ > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:332 > 2nd 0xffffffff81037368 smbsm (smbsm) @ > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:348 > > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xc2a > smb_co_lock() at smb_co_lock+0x38 > smb_co_gone() at smb_co_gone+0x38 > > smb_sm_lookup() at smb_sm_lookup+0xfe > smb_usr_lookup() at smb_usr_lookup+0xcd > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > giant_ioctl() at giant_ioctl+0x75 > devfs_ioctl_f() at devfs_ioctl_f+0x76 > kern_ioctl() at kern_ioctl+0x92 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1bf > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > 0x7fffffffe048, rbp = 0x7fffffffe460 --- I've updated the patch in order to fix smb_co_lockstatus problem. Could you please stress test it while I investigate the LOR problem? Are you running with INVARIANTS? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-fs@FreeBSD.ORG Sun Nov 2 20:34:10 2008 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 D42431065672 for ; Sun, 2 Nov 2008 20:34:10 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 79AA68FC18 for ; Sun, 2 Nov 2008 20:32:35 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so879833nfh.33 for ; Sun, 02 Nov 2008 12:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Fga0IzX4kjY+1XdCszPCJSpPVQwmaqWDh9rRpUh6Zg0=; b=kDCDcVNQvanMcDePQB0yUW2fwUScgwLvmzcjrHB9kER+iwMPzJnILMT5YcrZBRq6y0 YH5ggDqpx/WPAwy8E8YVdZNdfmo2a4wfGcpH2siHcCe4OUA2txrMupa/7a8efYwbOhoH 6yhQaHvq7aGcyzmkZbEGVGjn2zQI/MDjLLOdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=g5upUqeFJ7/B2I4HWhG9Qd1Nb386CAiYb878hvLSkeOoqNl53PvZwRVflFUTncw0cq ZpZJEI1IL7/Qnq8r/x/3p0hLkQ5xat1lf1IaGIfKHkTJMsTBb21P5FN19R+krO4X5IWY oNe+eMCVrf7TP7rIAgxdMQjX+5o10vQDGD9AA= Received: by 10.210.22.16 with SMTP id 16mr3599199ebv.132.1225657340829; Sun, 02 Nov 2008 12:22:20 -0800 (PST) Received: from darklight.homeunix.org ([85.175.24.53]) by mx.google.com with ESMTPS id u14sm12348777gvf.6.2008.11.02.12.22.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Nov 2008 12:22:20 -0800 (PST) Received: from darklight.homeunix.org (yuri@darklight.homeunix.org [127.0.0.1]) by darklight.homeunix.org (8.14.3/8.14.3) with ESMTP id mA2KMChr006700; Sun, 2 Nov 2008 23:22:17 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.homeunix.org (8.14.3/8.14.3/Submit) id mA2KMB3n006698; Sun, 2 Nov 2008 23:22:11 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.homeunix.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Sun, 2 Nov 2008 23:22:11 +0300 From: Yuri Pankov To: Attilio Rao Message-ID: <20081102202211.GA1549@darklight.homeunix.org> References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <20081102163307.GB1434@darklight.homeunix.org> <3bbf2fe10811020953l29f1a7eesa4f4eeb49f0a2eba@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10811020953l29f1a7eesa4f4eeb49f0a2eba@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 02 Nov 2008 20:34:10 -0000 On Sun, Nov 02, 2008 at 06:53:25PM +0100, Attilio Rao wrote: > 2008/11/2, Yuri Pankov : > > On Sun, Nov 02, 2008 at 05:17:18PM +0100, Attilio Rao wrote: > > > 2008/11/2, Attilio Rao : > > > > 2008/11/2, Yuri Pankov : > > > > > > > > > Hi, > > > > > > > > > > Trying to mount nonexistent smb share with mount_smbfs leads to > > > > > following panic: > > > > > > > > > > # mount_smbfs //yuri@lifebane/blahblah /mnt > > > > > > > > > > Unread portion of the kernel message buffer: > > > > > smb_co_lock: recursive lock for object 1 > > > > > panic: Lock (lockmgr) smb_vc not locked @ > > > > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329. > > > > > cpuid = 0 > > > > > KDB: stack backtrace: > > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > > panic() at panic+0x182 > > > > > witness_assert() at witness_assert+0x21a > > > > > __lockmgr_args() at __lockmgr_args+0x17a > > > > > smb_co_put() at smb_co_put+0x76 > > > > > smb_sm_lookup() at smb_sm_lookup+0xfe > > > > > smb_usr_lookup() at smb_usr_lookup+0xcd > > > > > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > > > > > giant_ioctl() at giant_ioctl+0x75 > > > > > devfs_ioctl_f() at devfs_ioctl_f+0x76 > > > > > kern_ioctl() at kern_ioctl+0x92 > > > > > ioctl() at ioctl+0xfd > > > > > syscall() at syscall+0x1bf > > > > > Xfast_syscall() at Xfast_syscall+0xab > > > > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > > > > 0x7fffffffe038, rbp = 0x7fffffffe450 --- > > > > > Uptime: 6m46s > > > > > Physical memory: 2032 MB > > > > > > > > > > > > So, what is happening here is that smb_co_lock() is AFU. > > > > Infact looking at the code: > > > > int > > > > smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td) > > > > { > > > > ... > > > > if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && > > > > (flags & LK_CANRECURSE) == 0) { > > > > SMBERROR("recursive lock for object %d\n", cp->co_level); > > > > return 0; > > > > } > > > > ... > > > > > > Yuri, > > > could you please test this fix: > > > http://www.freebsd.org/~attilio/netsmb.diff > > > > > > and report if it works? > > > You could get a KASSERT running but this is expected as I want to > > > identify on the callers who passes a malformed request and fix it. > > > > > > Thanks, > > > Attilio > > > > > > > > > -- > > > Peace can only be achieved by understanding - A. Einstein > > > > > > Thanks, Attilio. > > > > With this patch system doesn't panic anymore with nonexistent share > > names (though I had to comment out smb_co_lockstatus prototype and > > function to get rid of -Werror complaints). Still getting a LOR: > > > > netsmb_dev: loaded > > lock order reversal: > > 1st 0xffffff0021644008 smb_vc (smb_vc) @ > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:332 > > 2nd 0xffffffff81037368 smbsm (smbsm) @ > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:348 > > > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > > _witness_debugger() at _witness_debugger+0x2e > > witness_checkorder() at witness_checkorder+0x81e > > __lockmgr_args() at __lockmgr_args+0xc2a > > smb_co_lock() at smb_co_lock+0x38 > > smb_co_gone() at smb_co_gone+0x38 > > > > smb_sm_lookup() at smb_sm_lookup+0xfe > > smb_usr_lookup() at smb_usr_lookup+0xcd > > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > > giant_ioctl() at giant_ioctl+0x75 > > devfs_ioctl_f() at devfs_ioctl_f+0x76 > > kern_ioctl() at kern_ioctl+0x92 > > ioctl() at ioctl+0xfd > > syscall() at syscall+0x1bf > > Xfast_syscall() at Xfast_syscall+0xab > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > > > 0x7fffffffe048, rbp = 0x7fffffffe460 --- > > I've updated the patch in order to fix smb_co_lockstatus problem. > Could you please stress test it while I investigate the LOR problem? Not sure what do you mean by "stress test". I've tried mounting several different shares and copied ~100Gb from them, hope this should suffice. > Are you running with INVARIANTS? Yes. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein Thanks, Yuri From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 00:58:36 2008 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 4E31B1065673 for ; Mon, 3 Nov 2008 00:58:36 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA468FC19 for ; Mon, 3 Nov 2008 00:58:35 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 2573217E80; Mon, 3 Nov 2008 11:58:34 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.3 required=10.0 tests=ALL_TRUSTED, DNS_FROM_SECURITYSAGE autolearn=no version=3.2.3 Received: from [10.20.30.101] (60.218.233.220.exetel.com.au [220.233.218.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id EB79417E6C for ; Mon, 3 Nov 2008 11:58:29 +1100 (EST) Message-ID: <490E4CB1.5070704@modulus.org> Date: Mon, 03 Nov 2008 11:58:25 +1100 From: Andrew Snow User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: zfs snapshots sometimes give errors like "File name too long" 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, 03 Nov 2008 00:58:36 -0000 I have about 50 filesystems on July 8-current with pjd's patchset. While snapshotting works on most of them, occasionally after I create a snapshot and try to use it, I get errors like this: ls -la .zfs/snapshot ls: 20081031_20653: File name too long It does occur only on the longest ones, but they are nowhere near MAXNAMELEN (256) long, they are around 60 characters for the mount point plus another 14 for the snapshot name. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 10:36:49 2008 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 879991065676; Mon, 3 Nov 2008 10:36:49 +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 5EAB98FC0C; Mon, 3 Nov 2008 10:36:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA3AantM089159; Mon, 3 Nov 2008 10:36:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA3AanMH089155; Mon, 3 Nov 2008 10:36:49 GMT (envelope-from linimon) Date: Mon, 3 Nov 2008 10:36:49 GMT Message-Id: <200811031036.mA3AanMH089155@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128514: [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Adapter 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, 03 Nov 2008 10:36:49 -0000 Old Synopsis: ZFS and LSILogic SAS/SATA Adapter New Synopsis: [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Adapter Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 3 10:35:42 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128514 From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 11:06:52 2008 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 5AEB31065672 for ; Mon, 3 Nov 2008 11:06:52 +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 48F3C8FC29 for ; Mon, 3 Nov 2008 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA3B6qci010892 for ; Mon, 3 Nov 2008 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA3B6pLe010888 for freebsd-fs@FreeBSD.org; Mon, 3 Nov 2008 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Nov 2008 11:06:51 GMT Message-Id: <200811031106.mA3B6pLe010888@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, 03 Nov 2008 11:06:52 -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/128514 fs [zfs] [mpt] problems with ZFS and LSILogic SAS/SATA Ad o kern/128173 fs [ext2fs] ls gives "Input/output error" on mounted ext3 o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127213 fs [tmpfs] sendfile on tmpfs data corruption 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/125536 fs [ext2fs] ext 2 mounts cleanly but fails on commands li o kern/125149 fs [nfs][panic] changing into .zfs dir from nfs client ca o kern/124621 fs [ext3] Cannot mount ext2fs partition o kern/122888 fs [zfs] zfs hang w/ prefetch on, zil off while running t o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha a kern/119868 fs [zfs] [patch] 7.0 kernel panic during boot with ZFS an o bin/118249 fs mv(1): moving a directory changes its mtime o kern/116170 fs [panic] Kernel panic when mounting /tmp 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 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/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D 23 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 12:00:52 2008 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 311701065676 for ; Mon, 3 Nov 2008 12:00:52 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AA30D8FC2D for ; Mon, 3 Nov 2008 12:00:51 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Kwy6v-0007CK-PT for freebsd-fs@freebsd.org; Mon, 03 Nov 2008 12:00:45 +0000 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 ; Mon, 03 Nov 2008 12:00:45 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Nov 2008 12:00:45 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Ivan Voras Date: Mon, 03 Nov 2008 13:00:44 +0100 Lines: 60 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig05344683104B598858CB6FAD" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD 7.0: gjournal on root filesystem problems 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, 03 Nov 2008 12:00:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05344683104B598858CB6FAD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gabriel Lavoie wrote: > Hello, > I'm currently making some test to know how to setup a new home > fileserver using two 500GB hard drives. I want to create a gmirror/gjou= rnal > setup on the complete filesystem. I've been able to setup everything an= d it > works well. Now the problem I have is with the failure test. I create a= file > with random data on the / filesystem using "dd" and while whe file is b= eing > created, I hit the reset button of the computer. Now, it won't boot > anymore... I get the following message: >=20 > GEOM_MIRROR: Device mirror/gm launched (2/2) > GEOM_JOURNAL: Journal 3672855181: mirror/gma contains data. > GEOM_JOURNAL: Journal 3672855181: mirror/gma contains journal. > GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains data. > GEOM_JOURNAL: Journal 3868799910: mirror/gmd contains journal. > GEOM_JOURNAL: Journal mirror/gmd consistent. > Trying to mount root from ufs:/dev/mirror/gma.journal >=20 > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input >=20 >=20 > mountroot> ? >=20 > List of GEOM managed disk devices: > mirror/gmd.journal mirror/gmd mirror/gmc mirror/gma mirror/gm ad10= s1c > ad10s1b ad8s1c ad8s1b ad10s2 ad10s1 ad8s1 ad10 ad8 acd0 It looks like journal recovery takes too long and the journal devices isn't ready at the time the root file system needs to be mounted. --------------enig05344683104B598858CB6FAD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJDufsldnAQVacBcgRAsgLAJ4vqGifMxRxu7AXIVIALYMtoNNI2wCfZ3vz cdS+F/6IvSPjZLIkSmH1duk= =NVjx -----END PGP SIGNATURE----- --------------enig05344683104B598858CB6FAD-- From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 08:32:06 2008 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 9C0FC10656D3 for ; Mon, 3 Nov 2008 08:32:06 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: from web36603.mail.mud.yahoo.com (web36603.mail.mud.yahoo.com [209.191.85.20]) by mx1.freebsd.org (Postfix) with SMTP id 612738FC96 for ; Mon, 3 Nov 2008 08:32:06 +0000 (UTC) (envelope-from numisemis@yahoo.com) Received: (qmail 11377 invoked by uid 60001); 3 Nov 2008 08:31:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=RKu7u259kTzreffSpNXFk9DMe8CjgkhmK+ufQQdVcJxgBdydxSXHMUP7d4hjk03gc14zcBnAB7YvZCDUpOfchdPLmuFWfR7oUc/OuR/HMDv1BtQJXN86zaRl+R0dMRZN8GAuJaibFzJiMUxC+kV/Kdb1M1Zc6myeAYoaUSP8aJ8=; X-YMail-OSG: u9EQ1nMVM1lVEAdBNvlzduWxo4Rez.X_MZ8IgjjpQZzdMHKo1_cSkpr5AJ5yjld7eME4bLiGzlvplzEcgGNTgHBb39QxcBcQE7euxfPc4eEvrkpQZCAHDU10BIXri_sRKOMcPr_mnQh1PctqCXEZrhPR3OTlM9ELGUKmLPND Received: from [213.147.110.159] by web36603.mail.mud.yahoo.com via HTTP; Mon, 03 Nov 2008 00:31:57 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Mon, 3 Nov 2008 00:31:57 -0800 (PST) From: Simun Mikecin To: Peter Schuller MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <723911.11212.qm@web36603.mail.mud.yahoo.com> X-Mailman-Approved-At: Mon, 03 Nov 2008 12:24:03 +0000 Cc: freebsd-fs@freebsd.org Subject: Re: Areca vs. ZFS performance testing. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: numisemis@yahoo.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2008 08:32:06 -0000 Peter Schuller wrote: > In any case, why would the actual RAID controller cache be flushed, > unless someone expliclitly configured it such? I would expect a > regular BIO_FLUSH (that's all ZFS is going right?) to be satisfied by > the data being contained in the controller cache, under the assumption > that it is battery backed, and that the storage volume/controller has > not been explicitly configured otherwise to not rely on the battery > for persistence. I'm using amr(4) driver with Dell PERC 4e/DC controller (which is a rebranded LSI 320-2E) that has battery-backed cache and write-caching configured to be write-back. This controller is connected to a LED light that shows when there is something in the cache not yet commited to the disks. Ever since I changed from UFS2 to ZFS that light comes off very quickly. It does not stay on for longer periods of time (it did for upto 10 seconds when I used UFS2 - it is a controller BIOS setting). So doing BIO_FLUSH in this case *does* flush battery-backed cache. I can restore old functionality by setting vfs.zfs.cache_flush_disable=1 but I shouldn't use it in my case since the same system also has SATA disks with ZFS on them and turning off BIO_FLUSH for SATA disks would be dangerous. > Please correct me if I'm wrong, but if synchronous writing to your > RAID device results in actually waiting for underlying disks to commit > the data to platters, that sounds like a driver/controller > problem/policy issue rather than anything that should be fixed by > tweaking ZFS. AFAIK as I know BIO_FLUSH (which is for now implemeted only for ata(4) and amr(4) - correct me if I'm mistaken) does just that: actually flushes and waits for the cache content to be written on disk. > Or is it the case that ZFS does both a "regular" request to commit > data (which I thought was the purpose of BIO_FLUSH, even though the > "FLUSH" sounds more specific) and separately does a "flush any actual > caches no matter what" type of request that ends up bypassing > controller policy (because it is needed on stupid SATA drives or > such)? AFAIK BIO_FLUSH commits *everything* that is in the cache. It is needed for stupid SATA drives. But I'm not so happy about it been turned on for amr(4) flushing the entire 128MB battery backed cache. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 21:03:55 2008 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 C58C51065672; Mon, 3 Nov 2008 21:03:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED0B8FC12; Mon, 3 Nov 2008 21:03:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mA3L3mHm092949; Mon, 3 Nov 2008 16:03:49 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Mon, 3 Nov 2008 14:58:42 -0500 User-Agent: KMail/1.9.7 References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> In-Reply-To: <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811031458.42549.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 03 Nov 2008 16:03:49 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8560/Mon Nov 3 14:20:13 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Yuri Pankov , freebsd-fs@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 03 Nov 2008 21:03:55 -0000 On Sunday 02 November 2008 11:17:18 am Attilio Rao wrote: > 2008/11/2, Attilio Rao : > > 2008/11/2, Yuri Pankov : > > > > > Hi, > > > > > > Trying to mount nonexistent smb share with mount_smbfs leads to > > > following panic: > > > > > > # mount_smbfs //yuri@lifebane/blahblah /mnt > > > > > > Unread portion of the kernel message buffer: > > > smb_co_lock: recursive lock for object 1 > > > panic: Lock (lockmgr) smb_vc not locked @ > > > /usr/src/sys/modules/smbfs/../../netsmb/smb_conn.c:329. > > > cpuid = 0 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > panic() at panic+0x182 > > > witness_assert() at witness_assert+0x21a > > > __lockmgr_args() at __lockmgr_args+0x17a > > > smb_co_put() at smb_co_put+0x76 > > > smb_sm_lookup() at smb_sm_lookup+0xfe > > > smb_usr_lookup() at smb_usr_lookup+0xcd > > > nsmb_dev_ioctl() at nsmb_dev_ioctl+0x1f6 > > > giant_ioctl() at giant_ioctl+0x75 > > > devfs_ioctl_f() at devfs_ioctl_f+0x76 > > > kern_ioctl() at kern_ioctl+0x92 > > > ioctl() at ioctl+0xfd > > > syscall() at syscall+0x1bf > > > Xfast_syscall() at Xfast_syscall+0xab > > > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800939aec, rsp = > > > 0x7fffffffe038, rbp = 0x7fffffffe450 --- > > > Uptime: 6m46s > > > Physical memory: 2032 MB > > > > > > So, what is happening here is that smb_co_lock() is AFU. > > Infact looking at the code: > > int > > smb_co_lock(struct smb_connobj *cp, int flags, struct thread *td) > > { > > ... > > if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && > > (flags & LK_CANRECURSE) == 0) { > > SMBERROR("recursive lock for object %d\n", cp->co_level); > > return 0; > > } > > ... > > Yuri, > could you please test this fix: > http://www.freebsd.org/~attilio/netsmb.diff > > and report if it works? > You could get a KASSERT running but this is expected as I want to > identify on the callers who passes a malformed request and fix it. This allows all smb locks to recurse unlike the original code I think. It may be better if smb_vclist was initialized with LK_RECURSE, but not all the other smb locks. Also, in smb_co_addchild() I think you should just replace the existing asserts with appropriate lockmgr_assert() (you could add a smb_co_assert() to preserve the layering) rather than removing assertions altogether. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 21:07:28 2008 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 C4A1B106564A; Mon, 3 Nov 2008 21:07:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAAB8FC1C; Mon, 3 Nov 2008 21:07:28 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 3098B46B03; Mon, 3 Nov 2008 16:07:28 -0500 (EST) Date: Mon, 3 Nov 2008 21:07:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200811031458.42549.jhb@freebsd.org> Message-ID: References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <200811031458.42549.jhb@freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , Yuri Pankov , freebsd-current@freebsd.org, freebsd-fs@freebsd.org, developers@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 03 Nov 2008 21:07:28 -0000 On Mon, 3 Nov 2008, John Baldwin wrote: >> Yuri, could you please test this fix: >> http://www.freebsd.org/~attilio/netsmb.diff >> >> and report if it works? You could get a KASSERT running but this is >> expected as I want to identify on the callers who passes a malformed >> request and fix it. > > This allows all smb locks to recurse unlike the original code I think. It > may be better if smb_vclist was initialized with LK_RECURSE, but not all the > other smb locks. Also, in smb_co_addchild() I think you should just replace > the existing asserts with appropriate lockmgr_assert() (you could add a > smb_co_assert() to preserve the layering) rather than removing assertions > altogether. My general feeling is that the locking in netsmb needs a bit of cleanup, updating, etc. I'm reluctant to change the underlying primitives (as this patch does) without first clarifying what's going on in the code a layer or two above. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 21:20:06 2008 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 3DA20106567A; Mon, 3 Nov 2008 21:20:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 0E65D8FC14; Mon, 3 Nov 2008 21:20:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2333526fgb.35 for ; Mon, 03 Nov 2008 13:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=TA8VijrUjPMwnow6ltL/iEf838fcTkqmMcT11ctPE5s=; b=dw4JktMRvmXUhousKiX2YsaudebigugenOz5Jv5y3eq9jC+BUNpfeLzHfRWpL+pdp7 cuh4iF8Ra0+LpPRkVksVS0/jygjNF7C3uaxmPfKpaOfWyN1thXCP022vmsriwOZAeKCm xk55v2RCuWyWj9o6qIMTIhkoEGY9ZiM5lUy70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=tz9CX3/hdkWTxeISgfoOYqnbSt4luzLJau/CrhGO9wTYkNKeHb4ie5FPNfCLBZUjwW 40mCYKp16qavI8QRM/dMUJHN+xO/y3E6m7TrrVdFpYpKa8BUPEi00loNsgOOs5U+pIID Wy4uUyCG0r7zmQT45KJTrXNN7tkF9VwzE4P3s= Received: by 10.86.23.17 with SMTP id 17mr527417fgw.0.1225747203803; Mon, 03 Nov 2008 13:20:03 -0800 (PST) Received: by 10.86.2.18 with HTTP; Mon, 3 Nov 2008 13:20:03 -0800 (PST) Message-ID: <3bbf2fe10811031320o5d977babpe37bcf22836b8d34@mail.gmail.com> Date: Mon, 3 Nov 2008 22:20:03 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <200811031458.42549.jhb@freebsd.org> X-Google-Sender-Auth: 86ce34cb774d5f9b Cc: Yuri Pankov , freebsd-fs@freebsd.org, freebsd-current@freebsd.org, developers@freebsd.org, John Baldwin Subject: Re: reproducible panic with mount_smbfs 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, 03 Nov 2008 21:20:06 -0000 2008/11/3, Robert Watson : > On Mon, 3 Nov 2008, John Baldwin wrote: > > > > > > > Yuri, could you please test this fix: > http://www.freebsd.org/~attilio/netsmb.diff > > > > > > and report if it works? You could get a KASSERT running but this is > expected as I want to identify on the callers who passes a malformed request > and fix it. > > > > > > > This allows all smb locks to recurse unlike the original code I think. It > may be better if smb_vclist was initialized with LK_RECURSE, but not all the > other smb locks. Also, in smb_co_addchild() I think you should just replace > the existing asserts with appropriate lockmgr_assert() (you could add a > smb_co_assert() to preserve the layering) rather than removing assertions > altogether. > > > > My general feeling is that the locking in netsmb needs a bit of cleanup, > updating, etc. I'm reluctant to change the underlying primitives (as this > patch does) without first clarifying what's going on in the code a layer or > two above. I agree with Robert. We need to make an upper layers analysis and decide what is the best solution for locks. This was a quick hack just to let it not panic when mounting. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 22:48:18 2008 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 4B66D1065673; Mon, 3 Nov 2008 22:48:18 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) Received: from outbound.icp-qv1-irony-out3.iinet.net.au (outbound.icp-qv1-irony-out3.iinet.net.au [203.59.1.148]) by mx1.freebsd.org (Postfix) with ESMTP id D4F898FC08; Mon, 3 Nov 2008 22:48:16 +0000 (UTC) (envelope-from fbsd-fs@mawer.org) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioBACsHD0nLzq3r/2dsb2JhbAAIzBKDUg X-IronPort-AV: E=Sophos;i="4.33,538,1220198400"; d="scan'208";a="347147185" Received: from unknown (HELO [10.24.1.1]) ([203.206.173.235]) by outbound.icp-qv1-irony-out3.iinet.net.au with ESMTP; 04 Nov 2008 07:18:04 +0900 Message-ID: <490F77ED.9050501@mawer.org> Date: Tue, 04 Nov 2008 09:15:09 +1100 From: Antony Mawer User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Attilio Rao References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <200811031458.42549.jhb@freebsd.org> <3bbf2fe10811031320o5d977babpe37bcf22836b8d34@mail.gmail.com> In-Reply-To: <3bbf2fe10811031320o5d977babpe37bcf22836b8d34@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, developers@freebsd.org, John Baldwin , Yuri Pankov , freebsd-current@freebsd.org, Robert Watson Subject: Re: reproducible panic with mount_smbfs 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, 03 Nov 2008 22:48:18 -0000 Attilio Rao wrote: > 2008/11/3, Robert Watson : >> On Mon, 3 Nov 2008, John Baldwin wrote: >>>> Yuri, could you please test this fix: >> http://www.freebsd.org/~attilio/netsmb.diff >>>> and report if it works? You could get a KASSERT running but this is >> expected as I want to identify on the callers who passes a malformed request >> and fix it. >>> This allows all smb locks to recurse unlike the original code I think. It >> may be better if smb_vclist was initialized with LK_RECURSE, but not all the >> other smb locks. Also, in smb_co_addchild() I think you should just replace >> the existing asserts with appropriate lockmgr_assert() (you could add a >> smb_co_assert() to preserve the layering) rather than removing assertions >> altogether. >> My general feeling is that the locking in netsmb needs a bit of cleanup, >> updating, etc. I'm reluctant to change the underlying primitives (as this >> patch does) without first clarifying what's going on in the code a layer or >> two above. > > I agree with Robert. > We need to make an upper layers analysis and decide what is the best > solution for locks. > This was a quick hack just to let it not panic when mounting. This probably also applies to NWFS and netncp as well -- I haven't had a chance to test NWFS in 7.x as of yet, but will hope to do so in the coming months... --Antony From owner-freebsd-fs@FreeBSD.ORG Mon Nov 3 23:11:39 2008 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 87173106564A; Mon, 3 Nov 2008 23:11:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5B58D8FC1D; Mon, 3 Nov 2008 23:11:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id EFC5946B09; Mon, 3 Nov 2008 18:11:38 -0500 (EST) Date: Mon, 3 Nov 2008 23:11:38 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Antony Mawer In-Reply-To: <490F77ED.9050501@mawer.org> Message-ID: References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <200811031458.42549.jhb@freebsd.org> <3bbf2fe10811031320o5d977babpe37bcf22836b8d34@mail.gmail.com> <490F77ED.9050501@mawer.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Yuri Pankov , John Baldwin , developers@freebsd.org, Attilio Rao , freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 03 Nov 2008 23:11:39 -0000 On Tue, 4 Nov 2008, Antony Mawer wrote: > This probably also applies to NWFS and netncp as well -- I haven't had a > chance to test NWFS in 7.x as of yet, but will hope to do so in the coming > months... Ah, someone who actually uses netncp and nwfs! I've been trying to keep the ipx/spx code alive and working through the MPSAFE network stack work, but I'm really not set up to test that, let alone the Netware file system parts. Let us know how it goes. The netsmb and netncp code is well-structured, but designed with pre-SMPng locking primitives and network stack in mind, so will need quite a bit of work to pull forwards. As Attilio has already been running into, netsmb has rather intimate knowledge and reliance on some of the more obscure behaviors of lockmgr :-). This is something that will need to be fairly high on the list of things to change. Apple has started doing some of this in their fork of our netsmb code, but there's a lot more to do I think. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-fs@FreeBSD.ORG Tue Nov 4 00:15:42 2008 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 921F5106567F for ; Tue, 4 Nov 2008 00:15:42 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 5659A8FC37 for ; Tue, 4 Nov 2008 00:15:42 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2690112rvf.43 for ; Mon, 03 Nov 2008 16:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=yM+FHsPy1csdBkg5frw63cEOGw/gMHch2+S1Ue6Bp/k=; b=nFAUMl5eVcsWHwTE2nMETjfYMB/9dMuusNeCCemd1lBxyoJHn5Ay8e5JeWUCqlD5eQ 8OvidShtWmnOD8H02lXRlITbQmUEuR++CrvI+jKEZh5GM+MXeqyUp7lX0PsJYfiGcaM3 G08Vvicgt6XrFk5HYCe+dhobI5eFxn3N1KHcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GHFc8W7m4hrIiUkk1O0OabqlDkdMKEur+ejTFiPBt5Z0t+lzXWtRB9K9KI0LhO2Ig6 jZE/lxJKj9jLoEW1Kb22Hf1POKyYQZxlL5mtYGkIFAHp90zPiXfC+PWOHwogslTIUGVf 0U8yhPtjPH6ke12XqsN2DVSy58C00KvNd7o3M= Received: by 10.142.234.16 with SMTP id g16mr395173wfh.274.1225756457121; Mon, 03 Nov 2008 15:54:17 -0800 (PST) Received: by 10.142.218.14 with HTTP; Mon, 3 Nov 2008 15:54:17 -0800 (PST) Message-ID: <9bbcef730811031554m61bc6762g7f503ad56f0981bd@mail.gmail.com> Date: Tue, 4 Nov 2008 00:54:17 +0100 From: "Ivan Voras" To: "Robert Watson" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> <200811031458.42549.jhb@freebsd.org> <3bbf2fe10811031320o5d977babpe37bcf22836b8d34@mail.gmail.com> <490F77ED.9050501@mawer.org> Cc: Yuri Pankov , John Baldwin , developers@freebsd.org, Attilio Rao , freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 04 Nov 2008 00:15:42 -0000 2008/11/4 Robert Watson : >Apple has started doing > some of this in their fork of our netsmb code, but there's a lot more to do > I think. Like replacing SMB with CIFS :) I think that right now the only operating systems that use plain old SMB instead of CIFS are Windows 98, NT 4 and FreeBSD :) From owner-freebsd-fs@FreeBSD.ORG Tue Nov 4 03:32:28 2008 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 934011065674 for ; Tue, 4 Nov 2008 03:32:28 +0000 (UTC) (envelope-from borisxm@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 44E1C8FC1F for ; Tue, 4 Nov 2008 03:32:28 +0000 (UTC) (envelope-from borisxm@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1057062yxb.13 for ; Mon, 03 Nov 2008 19:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=fKra00DrGuGzXY3VOJNNImMG53K5a1WPEsJTXpA4Ozc=; b=saDGIhcLEDJFnHgO3vhRZ0IvGRKwDcTkIpVx0QCM9pXku/SPH7cHTMOej0Mtq4y3un vWi01ST5s0BXXR8KFTI589/hjQrP91W0ZU9zcM0IGTeJBLQcKHQsD4OZtT03N3oTNkHE gwiEefFJlH+YnMxDGVDo6IGuifnoOsskXnHM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=S1hu1b6akl19wT4rr52ex5yJgfON1OVy4HPW/M3NafVRBgrDRh77mN4/7dsU9YFE3G BiqgLVOuUPx7uRAyjrBLtMJAI29twuC2sl+5LLLoIysZuXq79X4V/O8bJN+2LX9idE99 0Vz+VZa3GhgR7HbG0dgC84webJFEpCpsdT8Es= Received: by 10.64.195.20 with SMTP id s20mr1163094qbf.20.1225768031925; Mon, 03 Nov 2008 19:07:11 -0800 (PST) Received: by 10.64.84.17 with HTTP; Mon, 3 Nov 2008 19:07:11 -0800 (PST) Message-ID: <35ab6dd50811031907t2ecd2ddeq82187464a1bbf3c0@mail.gmail.com> Date: Tue, 4 Nov 2008 09:07:11 +0600 From: "Boris Popov" Sender: borisxm@gmail.com To: "Attilio Rao" In-Reply-To: <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081102123100.GA1434@darklight.homeunix.org> <3bbf2fe10811020737g211dfb3fs54b48e4071db2393@mail.gmail.com> <3bbf2fe10811020817g1409a38ep26c1ee8edf075201@mail.gmail.com> X-Google-Sender-Auth: 08a9158a34bfd8c5 Cc: Yuri Pankov , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: reproducible panic with mount_smbfs 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, 04 Nov 2008 03:32:28 -0000 On Sun, Nov 2, 2008 at 10:17 PM, Attilio Rao wrote: > Yuri, > could you please test this fix: > http://www.freebsd.org/~attilio/netsmb.diff This patch looks wrong to me. AFAIR, the test (LK_EXCLUSIVE && (flags & LK_CANRECURSE)) were intended to prevent situations when SMB connection can not handle multiple requests (eg, during connection setup). But I do agree, that error processing of the lock status is bogus. -- Boris Popov From owner-freebsd-fs@FreeBSD.ORG Wed Nov 5 16:17:40 2008 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 93FFA106579D; Wed, 5 Nov 2008 16:17:40 +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 9FF678FC26; Wed, 5 Nov 2008 16:17:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 SAA10797; Wed, 05 Nov 2008 18:03:53 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4911C3E9.405@icyb.net.ua> Date: Wed, 05 Nov 2008 18:03:53 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.17 (X11/20080929) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? 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, 05 Nov 2008 16:17:40 -0000 Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I partitioned my disk for ZFS root file system more or less as described here: https://ish.com.au/solutions/articles/freebsdzfs Big difference is that I created a separate slice to contain a partition for ZFS pool, so that ZFS pool is ad4s2d (and UFS2 boot is ad4s1a). Everything was fine, ZFS root was mounted as expected. Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it couldn't mount ZFS root and I simply rebooted my machine when I stuck at mountroot prompt (I couldn't enter UFS2 root because of unrelated keyboard problem). The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART messages (errors, warnings). I'll try to debug this further by booting into UFS root and running gpart, but I'd like to ask for an advice upfront. Can something like this be rationally expected? Is there a way to make ZFS see its pool again (when booted into UFS root)? Thank you! -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Wed Nov 5 17:21:04 2008 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 42399106564A for ; Wed, 5 Nov 2008 17:21:04 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 1533B8FC18 for ; Wed, 5 Nov 2008 17:21:03 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by rv-out-0506.google.com with SMTP id b25so91267rvf.43 for ; Wed, 05 Nov 2008 09:21:03 -0800 (PST) Received: by 10.114.127.1 with SMTP id z1mr786474wac.10.1225904111805; Wed, 05 Nov 2008 08:55:11 -0800 (PST) Received: by 10.114.38.10 with HTTP; Wed, 5 Nov 2008 08:55:11 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 17:55:11 +0100 From: "=?ISO-8859-1?Q?Marius_N=FCnnerich?=" To: "Andriy Gapon" In-Reply-To: <4911C3E9.405@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4911C3E9.405@icyb.net.ua> Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? 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, 05 Nov 2008 17:21:04 -0000 On Wed, Nov 5, 2008 at 5:03 PM, Andriy Gapon wrote: > > Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I > partitioned my disk for ZFS root file system more or less as described here: > https://ish.com.au/solutions/articles/freebsdzfs > > Big difference is that I created a separate slice to contain a partition > for ZFS pool, so that ZFS pool is ad4s2d (and UFS2 boot is ad4s1a). > > Everything was fine, ZFS root was mounted as expected. > > Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and > options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it > couldn't mount ZFS root and I simply rebooted my machine when I stuck at > mountroot prompt (I couldn't enter UFS2 root because of unrelated > keyboard problem). > The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART > messages (errors, warnings). > > I'll try to debug this further by booting into UFS root and running > gpart, but I'd like to ask for an advice upfront. > > Can something like this be rationally expected? > Is there a way to make ZFS see its pool again (when booted into UFS root)? Afaict geom_part is a little bit more concerned about the correctness of the partition tables. I think it's possible that you have a bug in your tables which doesn't matter for geom_mbr or geom_bsd but for geom_part. From owner-freebsd-fs@FreeBSD.ORG Wed Nov 5 23:58:31 2008 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 2EC86106564A for ; Wed, 5 Nov 2008 23:58:31 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from hosted.kievnet.com (hosted.kievnet.com [193.138.144.10]) by mx1.freebsd.org (Postfix) with ESMTP id DA7688FC2F for ; Wed, 5 Nov 2008 23:58:30 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost ([127.0.0.1] helo=edge.pp.kiev.ua) by hosted.kievnet.com with esmtpa (Exim 4.62) (envelope-from ) id 1KxqQE-000NFG-Po; Thu, 06 Nov 2008 00:00:18 +0200 Message-ID: <49121772.1040501@icyb.net.ua> Date: Thu, 06 Nov 2008 00:00:18 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.17 (X11/20081005) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Marius_N=FCnnerich?= References: <4911C3E9.405@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-geom@freebsd.org Subject: Re: zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ? 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, 05 Nov 2008 23:58:31 -0000 on 05/11/2008 18:55 Marius Nünnerich said the following: > On Wed, Nov 5, 2008 at 5:03 PM, Andriy Gapon wrote: >> Using GENERIC amd64 7-BETA2 system (installed from "official" ISO) I >> partitioned my disk for ZFS root file system more or less as described here: >> https://ish.com.au/solutions/articles/freebsdzfs >> >> Big difference is that I created a separate slice to contain a partition >> for ZFS pool, so that ZFS pool is ad4s2d (and UFS2 boot is ad4s1a). >> >> Everything was fine, ZFS root was mounted as expected. >> >> Then I built a custom kernel with nooptions for GEOM_(BSD|MBR) and >> options for GEOM_PART_(BSD|MBR). When I tried to boot this kernel it >> couldn't mount ZFS root and I simply rebooted my machine when I stuck at >> mountroot prompt (I couldn't enter UFS2 root because of unrelated >> keyboard problem). >> The boot was verbose and I didn't see any peculiar GEOM or GEOM_PART >> messages (errors, warnings). >> >> I'll try to debug this further by booting into UFS root and running >> gpart, but I'd like to ask for an advice upfront. >> >> Can something like this be rationally expected? >> Is there a way to make ZFS see its pool again (when booted into UFS root)? > > Afaict geom_part is a little bit more concerned about the correctness > of the partition tables. I think it's possible that you have a bug in > your tables which doesn't matter for geom_mbr or geom_bsd but for > geom_part. I believe that disklabels are correct even for gpart, but this is not proven. Anyway I'll do more tests tomorrow. P.S. I kind of hoped for an advice on ZFS side of things. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Nov 6 11:25:20 2008 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 C23031065673; Thu, 6 Nov 2008 11:25:20 +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 99CE48FC2F; Thu, 6 Nov 2008 11:25:20 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA6BPKfR072270; Thu, 6 Nov 2008 11:25:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA6BPKXF072266; Thu, 6 Nov 2008 11:25:20 GMT (envelope-from linimon) Date: Thu, 6 Nov 2008 11:25:20 GMT Message-Id: <200811061125.mA6BPKXF072266@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/128633: [zfs] [lor] lock order reversal in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2008 11:25:20 -0000 Old Synopsis: lock order reversal in zfs New Synopsis: [zfs] [lor] lock order reversal in zfs Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 6 11:24:51 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128633 From owner-freebsd-fs@FreeBSD.ORG Thu Nov 6 11:44:21 2008 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 6865110656D7; Thu, 6 Nov 2008 11:44:21 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD9A8FC1E; Thu, 6 Nov 2008 11:44:21 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mA6BiLaO087908; Thu, 6 Nov 2008 11:44:21 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mA6BiLow087904; Thu, 6 Nov 2008 11:44:21 GMT (envelope-from gavin) Date: Thu, 6 Nov 2008 11:44:21 GMT Message-Id: <200811061144.mA6BiLow087904@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/119868: [geom_gpt] [patch] 7.0 kernel panic with corrupt GPT label 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, 06 Nov 2008 11:44:21 -0000 Old Synopsis: [zfs] [patch] 7.0 kernel panic during boot with ZFS and WD1600JS New Synopsis: [geom_gpt] [patch] 7.0 kernel panic with corrupt GPT label Responsible-Changed-From-To: freebsd-fs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Thu Nov 6 11:39:24 UTC 2008 Responsible-Changed-Why: Jaakko Heinonen points out that this is actually a bug with geom_gpt and not ZFS. The PR contains a patch, confirmed to fix the issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=119868 From owner-freebsd-fs@FreeBSD.ORG Sat Nov 8 00:16:58 2008 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 AB85E1065674 for ; Sat, 8 Nov 2008 00:16:58 +0000 (UTC) (envelope-from unxfbsdi@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mx1.freebsd.org (Postfix) with ESMTP id 470978FC1A for ; Sat, 8 Nov 2008 00:16:57 +0000 (UTC) (envelope-from unxfbsdi@gmail.com) Received: by ti-out-0910.google.com with SMTP id a1so255635tib.3 for ; Fri, 07 Nov 2008 16:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=H0IkRPHTyxJ46ZtvTVdqKmud87BhANIde+/x1BK8rm4=; b=AZS2BBiTeMwyNjTGkyPXvJNPKBiHLwnUV/4yaLzQVVxJXLpSgldC6uItSeSyBqGcb3 bHaHPhhvlNSkRR4LnrypVL4s/1UKJKDl13KGsCx2EFNBlCTAsquI0FD2wi+q2Umb//r/ xHd2DbeLqTTr/22+MNnPAEag9DvWuKXh7G4xs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=MbQ1FzLEVjYxx+4lwT6TLS8naFQB7cc04YV7QKSFe1u00WBq8z2crz3WoqWjBXFRC1 l2Ie3CoO+j/tf65yATKrgqXCKgtG1DzEwRHUBtoeSnFo7HiV0/G/dQr9K8e9aKfwTDu9 Zq43ERmuZddJOvBK2056cKlLQ+PtMctHEj6AU= Received: by 10.110.57.6 with SMTP id f6mr4453969tia.55.1226101957996; Fri, 07 Nov 2008 15:52:37 -0800 (PST) Received: from ?210.214.1.209? (static-210-214-1-209.maa.sify.net [210.214.1.209]) by mx.google.com with ESMTPS id y3sm2943501tia.6.2008.11.07.15.52.33 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Nov 2008 15:52:37 -0800 (PST) Message-ID: <4914D501.4090400@gmail.com> Date: Sat, 08 Nov 2008 05:23:37 +0530 From: Manish Jain User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary="------------090009080504050803020107" Subject: A problem with fork() and subsequent flock() 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, 08 Nov 2008 00:16:58 -0000 This is a multi-part message in MIME format. --------------090009080504050803020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I am starting out as a C/C++ programmer on FreeBSD and I am stuck with a small but irritating problem. I was trying out the flock() call and wrote flocksample.cpp, which starts out with a fork() and subsequent calls to flock() from both processes (parent as well as child; the child does an initial sleep(1) before anything else). It compiles okay and the parent's flock() call succeeds. But the child's flock() call too succeeds on the same file descriptor even before the first flock() unlocks. Can anyone please point out where the problem is ? I am not even sure whether the problem is FreeBSD specific. Attached is flocksample.cpp Thanks for any help Manish Jain unxfbsdi@gmail.com --------------090009080504050803020107 Content-Type: text/plain; name="flocksample.cpp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="flocksample.cpp" #include #include #include #include #include #include #include using namespace std; const char * szFileName = "/tmp/flock.log"; int addfunc(int fd); int readfunc(int fd); int main() { int fd = open(szFileName, O_RDWR | O_CREAT); assert(fd > 2); if (fork()) { return addfunc(fd); } else { cout << "Child sleeping for 1s before attempting to read log" << endl; sleep(1); //ensure that child's readfunc starts after parent's addfunc return readfunc(fd); } } int addfunc(int fd) { char buffer[4]; int i = 0; int result = flock(fd, LOCK_EX); assert(result == 0); while(i < 10) { sprintf(buffer, "%d\n\0", ++i); write(fd, buffer, strlen(buffer)); } while(*buffer != 'U') { cout << "Blocking on addfunc. Type U to unlock log" << endl; cin >> buffer; } cout << "Unblocking on addfunc ..." << endl; close(fd); //automatically calls LOCK_UN return 0; } int readfunc(int fd) { struct stat fstat; int result = flock(fd, LOCK_SH); assert(result == 0); cout << "readfunc got hold of log ..." << endl; lstat(szFileName, &fstat); char * buffer = new char[fstat.st_size + 1]; lseek(fd, 0, SEEK_SET); while (result < fstat.st_size) { result += read(fd, buffer + result, (fstat.st_size - result)); } close(fd); //automatically calls LOCK_UN buffer[result] = 0; cout << "Following are the contents of the file flock.log :" << endl; cout << buffer << endl; delete[] buffer; return 0; } --------------090009080504050803020107-- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 8 14:38:37 2008 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 1F0AA1065679 for ; Sat, 8 Nov 2008 14:38:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id B44428FC0A for ; Sat, 8 Nov 2008 14:38:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1KyoL8-0007Np-NJ; Sat, 08 Nov 2008 15:59:02 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mA8DwwPR074666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Nov 2008 15:58:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mA8DwwaZ040284; Sat, 8 Nov 2008 15:58:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mA8DwwGm040283; Sat, 8 Nov 2008 15:58:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 8 Nov 2008 15:58:57 +0200 From: Kostik Belousov To: Manish Jain Message-ID: <20081108135857.GH18100@deviant.kiev.zoral.com.ua> References: <4914D501.4090400@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BaAhobP9R+klFZfp" Content-Disposition: inline In-Reply-To: <4914D501.4090400@gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1KyoL8-0007Np-NJ 0bef9e9fc0f74d8bf9cd2c3173f3e111 X-Terabit: YES Cc: freebsd-fs@freebsd.org Subject: Re: A problem with fork() and subsequent flock() 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, 08 Nov 2008 14:38:37 -0000 --BaAhobP9R+klFZfp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 08, 2008 at 05:23:37AM +0530, Manish Jain wrote: >=20 > Hi, >=20 > I am starting out as a C/C++ programmer on FreeBSD and I am stuck with a= =20 > small but irritating problem. I was trying out the flock() call and=20 > wrote flocksample.cpp, which starts out with a fork() and subsequent=20 > calls to flock() from both processes (parent as well as child; the child= =20 > does an initial sleep(1) before anything else). It compiles okay and the= =20 > parent's flock() call succeeds. But the child's flock() call too=20 > succeeds on the same file descriptor even before the first flock()=20 > unlocks. Can anyone please point out where the problem is ? I am not=20 > even sure whether the problem is FreeBSD specific. This is right behaviour for flock. Note that manpage specifies that lock is attached to file. When you open a filedescriptor, you get the structure like that fd -> file -> vnode ,-> means references. Fork makes a copy of all fds opened in the process, and structure becomes fd [1] -> file -> vnode fd [2] / where fd[1] lives in parent, and fd[2] in child. Lock is still attached to file, so both parent and child share the lock. --BaAhobP9R+klFZfp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkkVmyEACgkQC3+MBN1Mb4h12ACfX/o6eL51AYGJRU8quBDpzQei tJsAnj83rJWWyxXf5R3SyyeW1AY3AqzE =Hnkw -----END PGP SIGNATURE----- --BaAhobP9R+klFZfp-- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 8 17:17:08 2008 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 8F1C5106567C for ; Sat, 8 Nov 2008 17:17:08 +0000 (UTC) (envelope-from znek@mulle-kybernetik.com) Received: from muller.mulle-kybernetik.com (port-212-202-151-204.static.qsc.de [212.202.151.204]) by mx1.freebsd.org (Postfix) with ESMTP id D79518FC12 for ; Sat, 8 Nov 2008 17:17:07 +0000 (UTC) (envelope-from znek@mulle-kybernetik.com) Received: (qmail 87356 invoked from network); 8 Nov 2008 16:50:42 -0000 Received: from unknown (HELO calculon.z.net) (znek@78.94.12.30) by mail.mulle-kybernetik.com with AES128-SHA encrypted SMTP; 8 Nov 2008 16:50:42 -0000 Message-Id: <73175263-4A61-4C87-9BF3-69ECC2CC0D17@mulle-kybernetik.com> From: =?ISO-8859-1?Q?Marcus_M=FCller?= To: freebsd-fs@freebsd.org In-Reply-To: <20081031201814.GA54286@server.vk2pj.dyndns.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 8 Nov 2008 17:50:23 +0100 References: <20080727125413.GG1345@garage.freebsd.pl> <86tzd490qx.fsf@gmail.com> <20080829074738.GB3026@garage.freebsd.pl> <20081031201814.GA54286@server.vk2pj.dyndns.org> X-Mailer: Apple Mail (2.929.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: ZFS patches. 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, 08 Nov 2008 17:17:08 -0000 On 01.11.2008, at 02:39, Peter Jeremy wrote: > Can you please give us an indication as to when we might expect to see > either an updated set of ZFS patches (or, better, the patches > committed > to -current). Me too. ;-) I just want to second that request. While I'm also still desperately waiting for an update, basically all I'd like to see at this point is a rough schedule when I/we could expect all the recent changes in Perforce to be in CVS HEAD for testing. Cheers, Marcus -- Marcus Mueller . . . crack-admin/coder ;-) Mulle kybernetiK . http://www.mulle-kybernetik.com Current projects: http://www.mulle-kybernetik.com/znek/ From owner-freebsd-fs@FreeBSD.ORG Sat Nov 8 21:10:06 2008 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 7344B10656F5 for ; Sat, 8 Nov 2008 21:10:06 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4B90A8FC16 for ; Sat, 8 Nov 2008 21:10:06 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 64.3.1.253.ptr.us.xo.net ([64.3.1.253]:7005 helo=LROSENMAN) by thebighonker.lerctr.org with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kyv4F-0008hS-Rn; Sat, 08 Nov 2008 15:10:05 -0600 From: "Larry Rosenman" To: =?iso-8859-1?Q?'Marcus_M=FCller'?= , References: <20080727125413.GG1345@garage.freebsd.pl> <86tzd490qx.fsf@gmail.com> <20080829074738.GB3026@garage.freebsd.pl> <20081031201814.GA54286@server.vk2pj.dyndns.org> <73175263-4A61-4C87-9BF3-69ECC2CC0D17@mulle-kybernetik.com> In-Reply-To: <73175263-4A61-4C87-9BF3-69ECC2CC0D17@mulle-kybernetik.com> Date: Sat, 8 Nov 2008 15:09:53 -0600 Message-ID: <005401c941e6$5e660e80$1b322b80$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclBxiUv5sJQFVplQoyckVQ3scv4LQAH+iNQ Content-Language: en-us X-Spam-Score: -2.3 (--) X-LERCTR-Spam-Score: -2.3 (--) X-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: Subject: RE: ZFS patches. 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, 08 Nov 2008 21:10:06 -0000 >On 01.11.2008, at 02:39, Peter Jeremy wrote: > >> Can you please give us an indication as to when we might expect to see >> either an updated set of ZFS patches (or, better, the patches >> committed >> to -current). > >Me too. ;-) I just want to second that request. While I'm also still >desperately waiting for an update, basically all I'd like to see at >this point is a rough schedule when I/we could expect all the recent >changes in Perforce to be in CVS HEAD for testing. I'd like to 3rd this request. I'm running a -CURRENT system from August with the patches and upgraded ZPOOL/ZFS's. I'd like to get more recent on the system sources, but I know there are issues with the ZFS patch, and would love to see the schedule or a new patch against recent HEAD. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893