Re: what's wrong with cd9660 fs
Hi, > for now i add -udf when using mkisofs and mount_udf reads fine. anyway i > would be happy to see fully working ISO filesystem, I am not a FreeBSD hacker but just lurking here for the topics of ISO 9660 and SCSI command transport to DVD burners. So i lack the knowledge to develop a patch. Nevertheless i am trying to understand how FreeBSD interprets the filesystem images which are produced by my software too. Meanwhile i learned that the UDF implementation in fs/udf does not provide a straightforward example for a multi-extent implementation in fs/cd9600. The udf vnodes have a 1:1 relation to ECMA-167 File Entries which have a 1:N relation to ECMA-167 Allocation Descriptors which describe the extents. For ISO 9660 one would need to submit multiple ECMA-119 Directory Records to the creator of a vnode. The directory records are stored in a continuous sequence in the image. A bit in their Flags field indicates whether there is another directory record of the same file following. In FreeBSD this would be a set of struct iso_directory_record. Only the fields iso_directory_record.extent, iso_directory_record.size, and iso_directory_record.flags are supposed to vary within the set. Bit 7 of iso_directory_record.flags is 1 if another record with the next extent of the same file follows. (ECMA-119 9.1.6 File Flags) struct iso_node would need to store the set of .extent and .size values instead of its components iso_node.iso_extent and iso_node.i_size. Then one could let cd9660_bmap() iterate over the set of extents like it is done by udf_bmap_internal(). The vnode is created in cd9660_vget_internal(), which gets called in cd9660_vfsops.c and in cd9660_lookup.c. The occasions in cd9660_vfsops.c submit directories and thus are not prone to multi-extent (ECMA-119 6.3 "Each directory shall be recorded as a file in a single Extent"). So the place to read multiple iso_directory_record before calling cd9660_vget_internal() seems to be in cd9660_lookup(): /* * Check for a name match. */ Well, here i got stopped for now by my lack of FreeBSD knowledge. > ISO filesystem, which is nearly optimal for read only usage. It has a few limitations. E.g. images cannot have more than 8 TiB size. But together with Rock Ridge it makes a fine backup filesystem, and even the most future-ish optical media plans to not yet reach the size limit. Have a nice day :) Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
CPU usage so high, fread() on the FILE wrapped by libfetch's fetchXGetURL()
Hi, I found the CPU usage is pretty high while running 'pkg update', 'pkg install [fooapp]'. Seems it was caused by fread() on the FILE wrapped by libfetch's fetchXGetURL() , maybe fetch_read() in common.c. Here is a simple test code: http://pastebin.com/2sP1f4Wv I want to know whether it is a bug, or misuse of libfetch API, or any other matter? Run and look about its CPU usage (HTTP url has this issue, FTP url has not): % ./a.out http://mirrors.163.com/FreeBSD/ISO-IMAGES-amd64/8.3/FreeBSD-8.3-RELEASE-amd64-bootonly.iso Env: % uname -a FreeBSD ThinkPad 9.0-STABLE FreeBSD 9.0-STABLE #1: Tue Apr 10 12:46:50 CST 2012 shen@ThinkPad:/usr/obj/usr/src/sys/ThinkPad amd64 -- Best regards, Yanhui Shen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
service causes ps errors in chroot
When I use '/usr/sbin/service' in chroot, it outputs: ps: empty file: Invalid argument OR ps: cannot read IdlePTD But it does work. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Status of BSD Diff replacement?
On Apr 21, 2012 4:15 PM, "Ben Fiedler" wrote: > > http://www.public.asu.edu/~bfiedler/bsdtextproc.tar.gz > > Here's a tar.gz of my project file: I did not include the diff/ directory, but instead gabor_diff/ , as that's where the latest changes are. iirc the original diff/ in my project was taken from the source for Gabor's 'bsdiff' under the ports tree, but then after a few weeks I discovered he had made newer changes to the code under perforce, so I based gabor_diff/ off of that. Sorry if this is all confusing :) > > -Ben Thanks a lot Ben. > > > > On Tue, Apr 17, 2012 at 8:30 PM, Matthew Story wrote: >> >> >> >> On Tue, Apr 17, 2012 at 10:01 PM, Ben Fiedler wrote: >>> >>> Gabor, >>> >>> I made a branch off of your perforce diff code in my work on the diff tool: From my understanding you started those modifications from OpenBSD's diff in 2008, so Matthew's assertion that "our incomplete BSD diff is OpenBSD diff + improvements" is 100% correct. I also ported and started work on sdiff and diff3 from OpenBSD, but made minimal headway on each. >>> >>> The red items on the table here lists the needed argument support to match GNU grep: http://wiki.freebsd.org/SOC2010BenFiedler#diff >> >> >> Awesome, thanks for that link. >> >>> >>> >>> >>> Though there's only a few left, they are not trivial by any means. >>> >>> -Ben >>> >>> >>> >>> On Tue, Apr 17, 2012 at 4:48 PM, Gabor Kovesdan wrote: On 2012.04.17. 23:03, Matthew Story wrote: > > Just wondering what the current status is on a BSD diff replacement. The IdeasPage suggests that a goodly amount of work was done on this for GSoC 2010 ( http://wiki.freebsd.org/IdeasPage#BSD-licensed_Text-Processing_Tools), but the GPLinBase page says it's unowned and suggests replacement with OpenBSD diff (http://wiki.freebsd.org/GPLinBase). Unless OpenBSD folks have changed or developed something, our incomplete BSD diff is OpenBSD diff + improvements. > > > Wondering how much is outstanding on this, and where to start reading to catch up on what's been done? I worked a bit on that in 2008 along with grep and sort but these got more priorities so lots of features are still missing. Then Ben Fiedler also worked on it in 2010 but I don't exactly know what he accomplished and whether he took my code or chose another way. So for someone who wants to work on it, first it should be checked what's done, maybe merge my version and Ben's version, >> >> >> just to verify, these are the correct 2 branches to look at: >> >> http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2008/&c=iZC@//depot/projects/soc2008/gabor_textproc/?ac=83 >> http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2010/&c=QTP@//depot/projects/soc2010/bsdtextproc/?ac=83 >> >> it looks like gabor_diff in soc2010 is based off the soc2008 work. >> >> Is there anyway either of you could provide me with an archive of the working tree for these 2 perforce repos? or make it available in a branch on svn.freebsd.org? I'd like to look into this more, but after reading through the P4Web docs, trying to gain anonymous read-only access through p4 itself, and then reading: >> >> http://lists.freebsd.org/pipermail/freebsd-questions/2007-August/156862.html >> >> it seems there's no real way to accommodate this sort of thing at current. >> check whether OpenBSD added something new or fixed somethings and then implement missing features and do lots of testing to ensure compatibility with GNU diff. And performance tests and improvements if necessary. >> >> >> Since 2008/2010 the OpenBSD change logs referencing diff(1) sdiff(1) and diff(3) are: >> >> 4.9 >> Use scandir(3) instead of getdirentries(2) in diff(1). Call to getdirentries(2) should be avoided outside of libc >> 4.8 >> Many diff(1) improvements. >> Make diff(1) return 2 on error. >> 4.6 >> Fix file descriptor leaks in sdiff(1) when diffing regular files. >> >> I think the many diff(1) improvements is when ray started maintaining diff (not millert), so perhaps I can ping him as well if I make any headway on this. >> I work on grep/regex related things and recently Oleg Moskalenko took over my incomplete BSD sort code but noone is working on BSD diff so any contribution is very welcome. Gabor >>> >>> >> >> >> >> -- >> regards, >> matt > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: what's wrong with cd9660 fs
Hi, there are problems in fs/cd9660 concerning multi-session, if the new session was written to addresses above 4 GiB. $ fetch https://dev.haiku-os.org/raw-attachment/ticket/8473/reloc_dir.iso.bz2 $ bunzip2 reloc_dir.iso.bz2 # mdconfig -a -t vnode -f reloc_dir.iso md1 # mount_cd9660 /dev/md1 /mnt # find /mnt /mnt # ls -ld /mnt -r-xr-xr-x 1 root wheel 0 Jan 1 1970 /mnt It must be related to Rock Ridge interpretation: # umount /mnt # mount_cd9660 -r /dev/md1 /mnt # find /mnt /mnt /mnt/deep_dir /mnt/deep_dir/1 /mnt/deep_dir/1/2 ... /mnt/7/file_7_1 # ls -ld /mnt dr-xr-xr-x 1 root wheel 2048 Apr 16 14:12 /mnt The image shows no visible problems with Linux kernels. The missing S_IFDIR property should get set by cd9660_rrip_attr() while cd9660_rrip_loop() iterates over the SUSP entries of ithe directory record. I see in /var/log/messages these two messages for each time i mount without option -r: Apr 22 14:11:39 freebsd1 kernel: cd9660: RockRidge Extension Apr 22 14:11:39 freebsd1 kernel: RRIP without PX field? My first candidate for the cause would be some 32 bit bottleneck in the computation of byte addresses of directory records. All the directory records which are pointed to by the PVDs of the images are stored above 4 GiB. (The PVDs are at block 16.) E.g. this gesture in cd9660_vfsops.c looks prone to rollover at 1 TiB (imp->im_bshift == 11 , DEV_BSHIFT == 9, sizeof(int) == 4) int lbn, off; [...] error = bread(imp->im_devvp, lbn << (imp->im_bshift - DEV_BSHIFT), imp->logical_block_size, NOCRED, &bp); This is a computation from 2 KiB block address to 512 byte block address. A similar lapse with byte addresses would already rollover at 4 GiB. Have a nice day :) Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool
On Sat, Apr 14, 2012 at 06:37:54PM +0300, Andriy Gapon wrote: > > I would like to ask for a review and/or testing of the following three > patches: > http://people.freebsd.org/~avg/zfsboot.patches.diff > > These patches add support for booting from an arbitrary filesystem of any > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > affectfrom where zfsloader would be loaded. zfsboot passes information about > the boot pool and filesystem to zfsloader, which uses those for loaddev and > default value of currdev. A different pool+filesystem could be selected in > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly > set > and is not derived from fstab, then it gets set to the selected boot > filesystem. > > This should could be used as a foundation for the support of Solaris-like boot > environment selection. I believe that other people have already developed > scripts utilizing ZFS capabilities to provide other aspects of management of > boot environments. > > I am particularly interested in reviews of my attempt to make ZFS boot support > arch-independent. The arches, of course, would have to add some code to make > use of that support. Currently I only enabled it for x86. > I can't say much about these patches as a whole as they are rather big and I'm not aware of all the details of ZFS. However, one bit that makes the current implementation x86-specific is zfs_dev_init(). If you could move it to the MD part in the course of these patches that would be great. If you could also take the second patch in PR 165025 into account, which I plan to commit once the issue with the current ofw_disk.c are properly solved, that would be great. Marius ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Can't unload snd_uaudio: it hangs in D+ state
I was debugging Logitech C910 webcam. 1. 'kldload snd_uaudio' while camera was attached 2. ran webcamd, which worked 3. stopped webcamd 4. 'kldunload snd_uaudio' while the camera is still attached => hanged in D+ 5. 'kldstat' also hangs in D+ I didn't really use usound, just loaded the module. What is wrong with snd_uaudio? Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Can't unload snd_uaudio: it hangs in D+ state
On Monday 23 April 2012 02:51:48 Yuri wrote: > I was debugging Logitech C910 webcam. > 1. 'kldload snd_uaudio' while camera was attached > 2. ran webcamd, which worked > 3. stopped webcamd > 4. 'kldunload snd_uaudio' while the camera is still attached => hanged in > D+ 5. 'kldstat' also hangs in D+ > I didn't really use usound, just loaded the module. > > What is wrong with snd_uaudio? Hi, If it says in dmesg that an application is using a device, that is a problem with the PCM layer, that doesn't support detach of devices if they are in use. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool
On 23.04.2012 1:21, Marius Strobl wrote: > I can't say much about these patches as a whole as they are rather > big and I'm not aware of all the details of ZFS. However, one bit that > makes the current implementation x86-specific is zfs_dev_init(). If > you could move it to the MD part in the course of these patches that > would be great. If you could also take the second patch in PR 165025 > into account, which I plan to commit once the issue with the current > ofw_disk.c are properly solved, that would be great. I also have some WIP related to moving partition table handling into MD part. You can look here: http://people.freebsd.org/~ae/sys_boot.diff This patch have one problem, there is no way to determine disk size and i'm thinking about adding ioctl(DIOCGMEDIASIZE) to the "disk" devsw. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: service causes ps errors in chroot
On 4/22/12 4:07 PM, rank1see...@gmail.com wrote: When I use '/usr/sbin/service' in chroot, it outputs: ps: empty file: Invalid argument OR ps: cannot read IdlePTD But it does work. I think you need devfs in your chroot. Try this: mount -t devfs devfs /path/to/chroot/dev -- Andrey Zonov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
