Re: Dump Utility cache efficiency analysis
Hello This is regarding the dump utility cache efficiency analysis post made on February '07 by Peter Jeremy [ http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html] and if this project is still open. I would be interested to begin exploring FreeBSD (and contributing) by starting this project. I do have some basic understanding of the problem at hand - to determine if a unified cache would appeal as a more efficient/elegant solution compared to the per-process-cache in the Dump utility implementation. I admit I am new to this list and FreeBSD so I wouldn't be able to determine what the current implementation is, until I get started. I would first like to understand the opinions of anyone who has looked at this problem or think this would be a worthwhile project to start off with. I would also appreciate if I could get simple tips and pointers of setting up my machine for the project. I understand this would be on the lines of: 1. Installing a stable FreeBSD build 2. Check out a version of the Build suitable for the project 3. Pointers to begin studying the current implementation in the code-tree structure (would I expect it to lie in the fs/ directory?). I tried to find it in the FreeBSD cross reference (http://fxr.watson.org/) 4. Read some important sections of the developer handbook (some suggestions would be great) Lastly- does this project require the know-how's of device drivers? If so, I would have to work harder. short answer: you don't need driver knowledge, but fs is a must. long answer: In the days long gone, the cpu/disk where slower than the tape, which could 'stream', and unless you could provide data fast enough, the tape would stop, rewind some, then pick up speed, and write. Nowadays, tapes are slower, but some/most of us dump to file, or pipe to restore (dump -f - ... | restore rf -), so that the tape speed is irrelevant. On the other hand, computers have much more memory, so buffering can be done by the OS. What I'm trying to say, and not wanting to take out any air from from the sails, is that dump should be re-valuated, and maybe OpenBSD/KIS is the best. danny Thanks a lot! - nirmal ___ 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 ___ 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: Dump Utility cache efficiency analysis
On 2009-Jun-23 15:52:04 -0400, Nirmal Thacker thacker.nir...@gmail.com wrote: I would first like to understand the opinions of anyone who has looked at this problem or think this would be a worthwhile project to start off with. I'm aware of the following references: http://www.mavetju.org/mail/view_message.php?list=freebsd-hackersid=375676 http://www.mavetju.org/mail/view_thread.php?list=freebsd-stableid=1335519thread=yes 1. Installing a stable FreeBSD build 2. Check out a version of the Build suitable for the project Any changes will need to apply to FreeBSD -current, though they may be back-ported once tested. This means that you will need a -current system at some point. 8-current is reasonably stable at this point and would be my suggestion. 3. Pointers to begin studying the current implementation in the code-tree structure (would I expect it to lie in the fs/ directory?). I tried to find it in the FreeBSD cross reference (http://fxr.watson.org/) The code is in src/sbin/dump. It references various system header files in order to understand the UFS on-disk format. Lastly- does this project require the know-how's of device drivers? If so, I would have to work harder. No. Dump is completely userland. -- Peter Jeremy pgpPzj39nQ3RN.pgp Description: PGP signature
Re: small usr.bin/find patch
hmmm...but dd e.g. uses lowercase instead of upercase letters to indicate kilobyte, megabyte and so on. isn't there some unix/posix/whatever standard telling app developers what to use? Wojciech Puchar schrieb am 2009-06-17: cheers. Are you sure this is wise? after all 125 millibytes would be 1 bit.. Agree. While lots of people use m instead of M and b instead of B, this is not right to correct proper behavior to improper just for them. ___ 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: small usr.bin/find patch
Alexander Best wrote: hmmm...but dd e.g. uses lowercase instead of upercase letters to indicate kilobyte, megabyte and so on. isn't there some unix/posix/whatever standard telling app developers what to use? Sure. The standard for scale-prefixes is defined by the Systeme Internationale as part of the definition of SI units: http://www.npl.co.uk/reference/measurement-units/si-prefixes/ Note that these are strictly powers-of-10^3 multipliers, and explicitly not the computing style powers-of-2^10 commonly used for file sizes or hard drive capacities, which should instead use the somewhat clunky Ki, Mi, Gi etc. forms: http://physics.nist.gov/cuu/Units/binary.html These binary prefixes are mandated by the IEC and approved by the IEEE amongst others. Not that many people use the binary prefixes appropriately, relying on context to disambiguate 1 MB = 1024 KB = 1,048,576 Bytes etc. Except that (confusingly) as a measure of network bandwidth 10 Mb/s always was 10,000,000 b/s and never 10,485,760 b/s; a fact that has caught me out more than a few times. Making find(1) / dd(1) / etc. operate pedantically correctly with these scale-factor symbols would cause a certain degree of pain for little practical gain. Unless there was a broad consensus amongst all Unixoid OS providers, I can't see that change ever happening. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. Flat 3 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW, UK signature.asc Description: OpenPGP digital signature
Re: small usr.bin/find patch
Alexander Best wrote: hmmm...but dd e.g. uses lowercase instead of upercase letters to indicate kilobyte, megabyte and so on. isn't there some unix/posix/whatever standard telling app developers what to use? It might be appropriate to use expand_number() here. This is what some other tools do as well and consistency between tools is a nice thing. Ciao, Johan pgpKTqoLnneUY.pgp Description: PGP signature
Re: Dump Utility cache efficiency analysis
On Tue, 23 Jun 2009 15:52:04 -0400 Nirmal Thacker thacker.nir...@gmail.com wrote: I would also appreciate if I could get simple tips and pointers of setting up my machine for the project. I understand this would be on the lines of: 1. Installing a stable FreeBSD build 2. Check out a version of the Build suitable for the project All development is taking place in -CURRENT, so you would have to check out this one, or you install it right away, it's not declared stable yet, but as we have started the release management process for 8.0, it's not that unstable either... :) 3. Pointers to begin studying the current implementation in the code-tree structure (would I expect it to lie in the fs/ directory?). I tried to find it in the FreeBSD cross reference (http://fxr.watson.org/) 4. Read some important sections of the developer handbook (some suggestions would be great) Dump is a complete userland implementation. All you need to know is the userland programming stuff, specially for what you want to do. You can find it online at http://svnweb.freebsd.org/viewvc/base/head/sbin/dump/ Bye, Alexander. ___ 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: small usr.bin/find patch
Quoting Alexander Best alexbes...@math.uni-muenster.de: hmmm...but dd e.g. uses lowercase instead of upercase letters to indicate kilobyte, megabyte and so on. isn't there some unix/posix/whatever standard telling app developers what to use? Actually thats only BSD's dd. GNU dd only accepts uppercase letters. pgpDWwEavbioX.pgp Description: PGP Digital Signature
8 week projects
My open source class this summer has a lot of people in it looking for 8 week projects. If you have a decently spec'd out project that a Junior/Senior CS student can accomplish, send me a link or pointer to it and I'll see if I can get the project some attention. Sean ___ 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: Dump Utility cache efficiency analysis
Thanks for all the replies and suggestions I ll begin by running, benchmarking, understanding dump for myself and take up Matt's suggestions above to understand the unified caching implementation in more detail -n On Wed, Jun 24, 2009 at 3:58 AM, Peter Jeremy peterjer...@optushome.com.auwrote: On 2009-Jun-23 15:52:04 -0400, Nirmal Thacker thacker.nir...@gmail.com wrote: I would first like to understand the opinions of anyone who has looked at this problem or think this would be a worthwhile project to start off with. I'm aware of the following references: http://www.mavetju.org/mail/view_message.php?list=freebsd-hackersid=375676 http://www.mavetju.org/mail/view_thread.php?list=freebsd-stableid=1335519thread=yes 1. Installing a stable FreeBSD build 2. Check out a version of the Build suitable for the project Any changes will need to apply to FreeBSD -current, though they may be back-ported once tested. This means that you will need a -current system at some point. 8-current is reasonably stable at this point and would be my suggestion. 3. Pointers to begin studying the current implementation in the code-tree structure (would I expect it to lie in the fs/ directory?). I tried to find it in the FreeBSD cross reference (http://fxr.watson.org/) The code is in src/sbin/dump. It references various system header files in order to understand the UFS on-disk format. Lastly- does this project require the know-how's of device drivers? If so, I would have to work harder. No. Dump is completely userland. -- Peter Jeremy ___ 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: dd copy of FreeBSD-7.2 won't boot
Personally id stay away from dd. Create the partitions and file systems manually, and install the boot loader, then rsync the data across. It will be a lot faster in most cases, as unlike dd you wont be copying unused space. Something like this should do the job Rsync -aPH --exclude=/mnt/** / /mnt I'm assuming you weren't migrating due to a bad disk -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Jim Flowers Sent: 23 June 2009 05:55 To: freebsd-hackers@freebsd.org Subject: dd copy of FreeBSD-7.2 won't boot I have a remote server that was dd copied from one hard drive to another - essentially the same size. The disk device name (ad4) is the same but the geometry for the new drive has a CHS of 969021/16/63 On booting it hangs at: F1FreeBSD Boot: F1 I copied the MBR with 'boot0cfg -B -opacket ad4' just to be sure but no joy. fbsd fdisk reports start 63, with CHS beg: 0/1/1 end: 1023/15/63. Any help on direction to solve this? Thanks. -- Jim Flowers jflow...@ezo.net ___ 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 ___ 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
