ctfconvert : failed to resolve types
I have a small snippet trying to study ctfconvert...
struct abc {
int length;
int bit;
union {
char key[0];
char *key_ptr[0];
} keys;
};
int main()
{
int a =1;
struct abc member = { 16, 5 };
printf("Sizeof abc structure [%d] \n", sizeof(struct abc));
}
% gcc -g ctfconvert_prob.c
% ctfconvert a.out
I get the following error on running "ctfconvert"...
ctfconvert_prob.c: failed to resolve the following types:
struct 362 <16a>: failed to size member "keys" of type __anon__ (297 <129>)
ERROR: ctfconvert_prob.c: failed to resolve types
How can ctfconvert be equipped to resolve this data type?
--
Shrikanth R K
___
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: head behaviour
On 05/06/2010 23:37, Bakul Shah wrote: > On Sat, 05 Jun 2010 14:02:16 PDT Doug Barton wrote: > It would be less surprising and more useful if > > $ ps | (head -1; grep ssh) > > showed > > PID TT STAT TIME COMMAND > > > The change in head behaviour I am suggesting wouldn't break > anything that already works but make it more useful for what > you call 'wacky commands lines'! I know this is besides the point you want to make, but I just cannot resist: # ps x | sed -e 1P -e '/ssh/\!d' -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: sysbench / fileio - Linux vs. FreeBSD
2010/6/5 Kostik Belousov > > On Sat, Jun 05, 2010 at 07:41:23PM +0200, Attilio Rao wrote: > > 2010/6/5 Matthew Jacob > > > > > > All of these tests have been apples vs. oranges for years. > > > > > > The following seems to be true, though: > > > > > > a) FreeBSD sequential write performance in UFS has always been less than > > > optimal. > > > > > > b) Linux sequential write performance in just about any filesystem has > > > always been "impressive". But that "impressive" has come at some not so > > > obvious costs. First of all, Linux is probably the most aggressive > > > cluster/write-behind OS I've even seen. You can suck down all available > > > memory with writebehind using dd. This means that some stats are > > > "impressive", and others are "painful". A desktop that becomes completely > > > unresponsive while you're doing this dd is one personal outcome. > > > > > > Also, you have to be careful what you're asking for in comparing the two > > > platforms, or any platforms for that matter. What do you want to optimize > > > for? Apparent responsiveness as a desktop? A specific workload (nfs, > > > cifs) that completes N quatloos per fortnight? > > > > Besides anything, I'm much more concerned about the loss of > > performance within FreeBSD itself. I wouldn't expect a so high > > pessimization when the number of threads increases (without > > considering the big performance loss with the 8k blocksize, pretty > > much reproducible). I'm trying to drive, privately, the tester to > > pmc/lock profiling analysis in order to start collecting some useful > > datas. > Are the benchmarks create threads that write to the same file ? > If yes, then this behaviour is well understood. Actually I still don't know as I just sent an e-mail to the tester and he didn't followup still. However I'm not entirely sure this is a full bottleneck which may be reconduit to missing of byte-range locking. I want to dig more and better understand what's going on exactly. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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"
Fwd: Re: Aurora Scheduler
Original Message Subject: Re: Aurora Scheduler Date: Sat, 05 Jun 2010 20:15:49 -0400 From: jhell To: Mohammed Farrag On 06/05/2010 19:23, Mohammed Farrag wrote: > Hi all, > thanx for ur reply. First Aurora shows the schedule in a series of > graphical displays that allow the user to see the resource allocations and > the temporal relationships among the elements. This display also allows the > user to edit the schedule directly and easily. Aurora focuses on resource > requirements and temporal scheduling in combination. > see that : > http://www.stottlerhenke.com/products/aurora/?gclid=CNn85aj0iaICFVKX2Aodam_wVQ#challenge > and http://sbir.nasa.gov/SBIR/successes/ss/10-020text.html > it is used in very large projects and used to manage resources. I was > asking about the algorithm it use in scheduling process and we can apply it > to FreeBSD processes for scheduling. > Second, I know that it is not available in native FreeBSD so I intend to > build it manually but I just need the algorithm it use to schedule processes > based on resources and complex constraints. > Good Luck, > Mohammed Farrag > I'm afraid that you are confused about what the scheduler in the FreeBSD kernel does and what the Aurora Scheduler is. They are not relational to one another in any such way. http://sbir.nasa.gov/SBIR/successes/ss/10-020text.html There is not a similiar scheduling program in FreeBSD but there is Evolution, Kontact and other such things to manage your time. Good Luck -- jhell ___ 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: Aurora Scheduler
On 06/05/2010 18:32, Mohammed Farrag wrote: > Hi group, > I am working on developing a new freebsd kernel theme for embedded. I was > searching for the best scheduler. I think the best one is Aurora Scheduler > developed by NASA. > I found that it can be included in the configuration file in the freebsd but > the problem was "Is it available for use by users"? the other one was where > I can find its technique. > Good luck, > Mohammed Farrag > ___ > 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" SCHED_ULE or SCHED_4BSD Thats your two options with ULE being the default in recent 8.0+ systems. Use ( sysctl kern.sched.name ) to determine which one you are using. Unless I misunderstood the intention of your message I would say that you are a bit confused about what the Aurora Scheduler is/means as compared to what FreeBSD uses as sched_ule(4) or sched_4bsd(4). Regards, -- jhell ___ 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: Aurora Scheduler
On 6/5/10 3:32 PM, Mohammed Farrag wrote: Hi group, I am working on developing a new freebsd kernel theme for embedded. I was searching for the best scheduler. I think the best one is Aurora Scheduler developed by NASA. I found that it can be included in the configuration file in the freebsd but the problem was "Is it available for use by users"? the other one was where I can find its technique. I'm somewhat confused. The aurora scheduler is for scheduling events such as meetings etc. I think. If I've got a teh wrong idea can you provide a pointer? Good luck, Mohammed Farrag ___ 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"
Aurora Scheduler
Hi group, I am working on developing a new freebsd kernel theme for embedded. I was searching for the best scheduler. I think the best one is Aurora Scheduler developed by NASA. I found that it can be included in the configuration file in the freebsd but the problem was "Is it available for use by users"? the other one was where I can find its technique. Good luck, Mohammed Farrag ___ 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: head behaviour
On Sat, 05 Jun 2010 17:02:42 EDT Mike Meyer wrote: > As a general rule, programs don't expect to share their input with > other programs, nor do they make guarantees about what is and isn't > read from that input under those conditions. I'd say that shell > scripts that depend on what some command does with it's unprocessed > input are buggy. Fair enough. Thanks! ___ 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: head behaviour
On Sat, 05 Jun 2010 14:02:16 PDT Doug Barton wrote: > On 06/05/10 13:48, Bakul Shah wrote: > > Without running the following can you guess its output? > > > > $ look '' | (head -2; head -2) > > Again, it's not clear to me what you expect is going to happen with the > second 'head -2' there. I agree that the actual output of your example > is wacky and unexpected, but what I'm trying to get you say is what YOU > think should happen. The examples that you pasted in your previous post > did not and could not do what you said you wanted them to do, so I don't > quite understand what the bug is. There is no bug per se. What I am saying that it would be *less surprising* if $ look '' | (head -2; head -2) behaved the same as $ look '' | head -4 [And yes, I would use head -4 if I wanted four lines but the example was to illustrate the issue that head buffers more than it needs to]. It would be less surprising and more useful if $ ps | (head -1; grep ssh) showed PID TT STAT TIME COMMAND The change in head behaviour I am suggesting wouldn't break anything that already works but make it more useful for what you call 'wacky commands lines'! > Put more simply, if you generate wacky command lines you should not be > surprised when they produce wacky results. :) I didn't realize that use of ;(|) constitutes wackiness :-) They are simply exercising the power of shell! We have used these commands for so long that we take them for granted and we learn to avoid their use in such ways. When Rob Warnock first mentioned this, my initial reaction was the same as yours. But thinking more about it, I felt head can be made more useful with this change and felt it was worth bringing it to people's attention. But we can let it rest. ___ 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: head behaviour
On 06/05/10 13:48, Bakul Shah wrote: Without running the following can you guess its output? $ look '' | (head -2; head -2) Again, it's not clear to me what you expect is going to happen with the second 'head -2' there. I agree that the actual output of your example is wacky and unexpected, but what I'm trying to get you say is what YOU think should happen. The examples that you pasted in your previous post did not and could not do what you said you wanted them to do, so I don't quite understand what the bug is. Put more simply, if you generate wacky command lines you should not be surprised when they produce wacky results. :) Doug On two occasions I have been asked [by members of Parliament!], "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: head behaviour
On Sat, 05 Jun 2010 13:32:08 PDT Doug Barton wrote: > On 06/05/10 13:12, Bakul Shah wrote: > > Consider: > > > > $ yes | cat -n | (read a; echo $a; head -1) > > 1 y > > 2 y > > > > $ yes | cat -n | (head -1; read a; echo $a) > > 1 y > > 456 y > > It's not at all clear to me what you are trying to accomplish here. If > what you want is to read only the first line of the output of yes, then > what you'd want to do is: > > yes | cat -n | head -1 | (read a; echo $a) > 1 y > > > As you can see, head reads far more than it should. This is > > fine most of the time but often it results in surprising > > output: > > > > # print ps header and all lines with sh in it > > $ ps|(head -1; grep sh) > >PID TT STAT TIME COMMAND > > I don't understand why you think this would work. There is no input to > the grep command. The only reason it exits at all is that you are > executing in a subshell. > > > # print first and last two lines > > $ look xa | (head -2; tail -2) > > xanthaline > > xanthamic > > Same problem here. There is no input to the tail command. In general this is not true. Without running the following can you guess its output? $ look '' | (head -2; head -2) Will it produce A a or A a aa aal or A a sive abrastol or something else? Yes, we can always find a work around for a given case but the issue is that head buffers up more than it needs to. ___ 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: head behaviour
On 06/05/10 13:12, Bakul Shah wrote: Consider: $ yes | cat -n | (read a; echo $a; head -1) 1 y 2 y $ yes | cat -n | (head -1; read a; echo $a) 1 y 456 y It's not at all clear to me what you are trying to accomplish here. If what you want is to read only the first line of the output of yes, then what you'd want to do is: yes | cat -n | head -1 | (read a; echo $a) 1 y As you can see, head reads far more than it should. This is fine most of the time but often it results in surprising output: # print ps header and all lines with sh in it $ ps|(head -1; grep sh) PID TT STAT TIME COMMAND I don't understand why you think this would work. There is no input to the grep command. The only reason it exits at all is that you are executing in a subshell. # print first and last two lines $ look xa | (head -2; tail -2) xanthaline xanthamic Same problem here. There is no input to the tail command. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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"
head behaviour
Consider: $ yes | cat -n | (read a; echo $a; head -1) 1 y 2 y $ yes | cat -n | (head -1; read a; echo $a) 1 y 456 y As you can see, head reads far more than it should. This is fine most of the time but often it results in surprising output: # print ps header and all lines with sh in it $ ps|(head -1; grep sh) PID TT STAT TIME COMMAND # print first and last two lines $ look xa | (head -2; tail -2) xanthaline xanthamic Not quite what you expected, right? Yes, you can use read and echo N times but this is not as convenient as using head: $ look xa | (read a; echo $a; read a; echo $a; tail -2) xanthaline xanthamic xarque Xaverian The "fix" is to make sure head reads no more than $N bytes where $N is the number of *remaining* lines to be read. Yes this slows head down some but makes it more useful. [Ideally all commands that quit after partially reading their input ought to behave like this but that would slow down their common use far too much] Comments? Thanks to Rob Warnock for pointing out the head problem. ___ 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: sysbench / fileio - Linux vs. FreeBSD
On Sat, Jun 05, 2010 at 07:41:23PM +0200, Attilio Rao wrote: > 2010/6/5 Matthew Jacob > > > > All of these tests have been apples vs. oranges for years. > > > > The following seems to be true, though: > > > > a) FreeBSD sequential write performance in UFS has always been less than > > optimal. > > > > b) Linux sequential write performance in just about any filesystem has > > always been "impressive". But that "impressive" has come at some not so > > obvious costs. First of all, Linux is probably the most aggressive > > cluster/write-behind OS I've even seen. You can suck down all available > > memory with writebehind using dd. This means that some stats are > > "impressive", and others are "painful". A desktop that becomes completely > > unresponsive while you're doing this dd is one personal outcome. > > > > Also, you have to be careful what you're asking for in comparing the two > > platforms, or any platforms for that matter. What do you want to optimize > > for? Apparent responsiveness as a desktop? A specific workload (nfs, cifs) > > that completes N quatloos per fortnight? > > Besides anything, I'm much more concerned about the loss of > performance within FreeBSD itself. I wouldn't expect a so high > pessimization when the number of threads increases (without > considering the big performance loss with the 8k blocksize, pretty > much reproducible). I'm trying to drive, privately, the tester to > pmc/lock profiling analysis in order to start collecting some useful > datas. Are the benchmarks create threads that write to the same file ? If yes, then this behaviour is well understood. > While I think that we might pay a lot of attention to ZFS, I think we > might not leave alone FFS. Having a fast, well supported, native > filesystem might be a great thing for us. > > Comparing with other operating systems, as you smartly point out, > might not be got as 'undefeatable truths' but have cons and prons that > needs to be fully understood before to make false claims. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > ___ > 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" pgp7XdlVh03Ug.pgp Description: PGP signature
Re: sysbench / fileio - Linux vs. FreeBSD
2010/6/5 Matthew Jacob > > All of these tests have been apples vs. oranges for years. > > The following seems to be true, though: > > a) FreeBSD sequential write performance in UFS has always been less than > optimal. > > b) Linux sequential write performance in just about any filesystem has always > been "impressive". But that "impressive" has come at some not so obvious > costs. First of all, Linux is probably the most aggressive > cluster/write-behind OS I've even seen. You can suck down all available > memory with writebehind using dd. This means that some stats are > "impressive", and others are "painful". A desktop that becomes completely > unresponsive while you're doing this dd is one personal outcome. > > Also, you have to be careful what you're asking for in comparing the two > platforms, or any platforms for that matter. What do you want to optimize > for? Apparent responsiveness as a desktop? A specific workload (nfs, cifs) > that completes N quatloos per fortnight? Besides anything, I'm much more concerned about the loss of performance within FreeBSD itself. I wouldn't expect a so high pessimization when the number of threads increases (without considering the big performance loss with the 8k blocksize, pretty much reproducible). I'm trying to drive, privately, the tester to pmc/lock profiling analysis in order to start collecting some useful datas. While I think that we might pay a lot of attention to ZFS, I think we might not leave alone FFS. Having a fast, well supported, native filesystem might be a great thing for us. Comparing with other operating systems, as you smartly point out, might not be got as 'undefeatable truths' but have cons and prons that needs to be fully understood before to make false claims. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: sysbench / fileio - Linux vs. FreeBSD
On Saturday 05 June 2010 01:58:35 Adam PAPAI wrote: > Why FreeBSD is supreme with 1 and 2 thread. And why is it 2 and 3 times > slower with 4-8-16-32 threads compared to Debian? The first two tests (1 > thread and 2 thread) showed me that FreeBSD is supreme in I/O, but later > tests showed me, that it can produce horrible I/O. > > How can I tune my disk to make it faster? Is it possible? What is the > reason of the really slow I/O with more than 4 threads? What do you > recommend me to do? Why is it damn slow with 8K blocksize? You may find this interesting: http://info.iet.unipi.it/~luigi/geom_sched/ Regards, Max ___ 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: sysbench / fileio - Linux vs. FreeBSD
All of these tests have been apples vs. oranges for years. The following seems to be true, though: a) FreeBSD sequential write performance in UFS has always been less than optimal. b) Linux sequential write performance in just about any filesystem has always been "impressive". But that "impressive" has come at some not so obvious costs. First of all, Linux is probably the most aggressive cluster/write-behind OS I've even seen. You can suck down all available memory with writebehind using dd. This means that some stats are "impressive", and others are "painful". A desktop that becomes completely unresponsive while you're doing this dd is one personal outcome. Also, you have to be careful what you're asking for in comparing the two platforms, or any platforms for that matter. What do you want to optimize for? Apparent responsiveness as a desktop? A specific workload (nfs, cifs) that completes N quatloos per fortnight? ___ 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: sysbench / fileio - Linux vs. FreeBSD
On 6/5/10 12:26 AM, Adam PAPAI wrote: On 6/5/10 3:36 AM, Bruce Cran wrote: Some quick tests show that ufs does do rather poorly on my system too. I have the following filesystems setup: /var : ufs with softupdates /usr/obj : zfs with checksums disabled /usr/src : zfs with compression enabled /home : zfs with compression disabled and checksums enabled I ran a test with a blocksize of 8KB and 16 threads. /var : 25.2MB/s /usr/obj : 64.8MB/s /usr/src : 386.3MB/s /home : 60.3MB/s It seems I have to test it with zfs as well. Tomorrow I'm gonna test it. Then the linux people will insist you use btrfs to compare apples to apples ... etc... etc.. ___ 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: sysbench / fileio - Linux vs. FreeBSD
/usr/src : zfs with compression enabled /usr/src : 386.3MB/s >>> Do I understand it well? It seems that zfs with compression enabled on >>> /usr/src with 8KB block size and 16 threads performs 386.3MB/s which >>> is about 6 times better than debian5? I am thinking about this image >>> http://tech-blog.wooh.hu/~wooh/debian_vs_freebsd_io_16_seqwr.png >> >> Yes - on one run it even hit 500MB/s. I suspect, however, that the >> benchmark isn't accurate because it won't be writing typical data. >> Instead it's probably using a buffer that compresses very well. > > Hm.. My ZFS tests showed me the same results. With compression it's > pretty fast. That's hardly a surprise - you take the source code, compress it into virtual non-existence leaving hardly anything to be written to the disk... Obviously if compression speed >> IO speed and the result of the compression is a significant reduction in size, you have a massive gain in writing that data to the disk. -- Igor ___ 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: sysbench / fileio - Linux vs. FreeBSD
> /var : ufs with softupdates > /usr/obj : zfs with checksums disabled > /usr/src : zfs with compression enabled > /home : zfs with compression disabled and checksums enabled > > I ran a test with a blocksize of 8KB and 16 threads. > > /var : 25.2MB/s > /usr/obj : 64.8MB/s > /usr/src : 386.3MB/s > /home : 60.3MB/s Do I understand it well? It seems that zfs with compression enabled on /usr/src with 8KB block size and 16 threads performs 386.3MB/s which is about 6 times better than debian5? I am thinking about this image http://tech-blog.wooh.hu/~wooh/debian_vs_freebsd_io_16_seqwr.png what is your system specs? ___ 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: sysbench / fileio - Linux vs. FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/5/10 1:04 PM, Bruce Cran wrote: > On Sat, 5 Jun 2010 12:50:15 +0200 > Stefan Miklosovic wrote: > >>> /var : ufs with softupdates >>> /usr/obj : zfs with checksums disabled >>> /usr/src : zfs with compression enabled >>> /home : zfs with compression disabled and checksums enabled >>> >>> I ran a test with a blocksize of 8KB and 16 threads. >>> >>> /var : 25.2MB/s >>> /usr/obj : 64.8MB/s >>> /usr/src : 386.3MB/s >>> /home : 60.3MB/s >> >> Do I understand it well? It seems that zfs with compression enabled on >> /usr/src with 8KB block size and 16 threads performs 386.3MB/s which >> is about 6 times better than debian5? I am thinking about this image >> http://tech-blog.wooh.hu/~wooh/debian_vs_freebsd_io_16_seqwr.png > > Yes - on one run it even hit 500MB/s. I suspect, however, that the > benchmark isn't accurate because it won't be writing typical data. > Instead it's probably using a buffer that compresses very well. Hm.. My ZFS tests showed me the same results. With compression it's pretty fast. An application benchmark will give us typical data write, so I'll run PgSQL benchmarks on the ZFS pool as well. - -- Adam PAPAI NETIDEA Informatikai Szolgáltató Kft. http://www.netidea.hu E-mail: w...@wooh.hu Phone: +36 30 33-55-735 (Hungary) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMCjJiAAoJEGq0EWvh5uiIKFMH/1dP4OZGAMiBNSoRqGFfnZ5B /vtf5do2t3JRbjfYi2HyNn8gXss4xRDPouVmftl2OglIXA77hMIyIcjyoWnHGTBc M1WnnNDz1wIb8EYSl9MYKAjQA1wGsYd4UImd1MqOtZfSuOht6hTLoSiAnC1xMLtk 9vgFUtMok8XclPqL08J/dWs39+HwhSaooRnLEx7IYLSgFis7vQtJjOaWWG3LUADw QsivcCSjBBoQ7LD9WXN5prmlwt+CMBU/F1yyMaJXa0bNI7AM+hh5Mix03P4HAKEz 4Z92lcmLXzSVnllA0tAJvAwEPtk4laP6yzM9egStDNvxONLueQVLXfY8gvukQ2k= =MVI2 -END PGP SIGNATURE- ___ 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: sysbench / fileio - Linux vs. FreeBSD
On Sat, 5 Jun 2010 12:50:15 +0200 Stefan Miklosovic wrote: > > /var : ufs with softupdates > > /usr/obj : zfs with checksums disabled > > /usr/src : zfs with compression enabled > > /home : zfs with compression disabled and checksums enabled > > > > I ran a test with a blocksize of 8KB and 16 threads. > > > > /var : 25.2MB/s > > /usr/obj : 64.8MB/s > > /usr/src : 386.3MB/s > > /home : 60.3MB/s > > Do I understand it well? It seems that zfs with compression enabled on > /usr/src with 8KB block size and 16 threads performs 386.3MB/s which > is about 6 times better than debian5? I am thinking about this image > http://tech-blog.wooh.hu/~wooh/debian_vs_freebsd_io_16_seqwr.png Yes - on one run it even hit 500MB/s. I suspect, however, that the benchmark isn't accurate because it won't be writing typical data. Instead it's probably using a buffer that compresses very well. -- Bruce Cran ___ 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: sysbench / fileio - Linux vs. FreeBSD
On 6/5/10 3:36 AM, Bruce Cran wrote: > Some quick tests show that ufs does do rather poorly on my system too. I have > the following filesystems setup: > > /var : ufs with softupdates > /usr/obj : zfs with checksums disabled > /usr/src : zfs with compression enabled > /home : zfs with compression disabled and checksums enabled > > I ran a test with a blocksize of 8KB and 16 threads. > > /var : 25.2MB/s > /usr/obj : 64.8MB/s > /usr/src : 386.3MB/s > /home : 60.3MB/s > It seems I have to test it with zfs as well. Tomorrow I'm gonna test it. -- Adam PAPAI ___ 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"
