<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_28_1422253</id>
	<title>HDD Manufacturers Moving To 4096-Byte Sectors</title>
	<author>CmdrTaco</author>
	<datestamp>1262014200000</datestamp>
	<htmltext>Luminous Coward writes <i>"As <a href="//hardware.slashdot.org/story/06/03/24/0619231/Changes-in-HDD-Sector-Usage-After-30-Years">previously discussed</a> on Slashdot, according to <a href="http://anandtech.com/storage/showdoc.aspx?i=3691">AnandTech</a> and <a href="http://techreport.com/discussions.x/18115">The Tech Report</a>, hard disk drive manufacturers are now ready to bump the size of the disk sector from 512 to 4096 bytes, in order to minimize storage lost to ECC and sync. This may not be a smooth transition, because some OSes do not align partitions on 4K boundaries."</i></htmltext>
<tokenext>Luminous Coward writes " As previously discussed on Slashdot , according to AnandTech and The Tech Report , hard disk drive manufacturers are now ready to bump the size of the disk sector from 512 to 4096 bytes , in order to minimize storage lost to ECC and sync .
This may not be a smooth transition , because some OSes do not align partitions on 4K boundaries .
"</tokentext>
<sentencetext>Luminous Coward writes "As previously discussed on Slashdot, according to AnandTech and The Tech Report, hard disk drive manufacturers are now ready to bump the size of the disk sector from 512 to 4096 bytes, in order to minimize storage lost to ECC and sync.
This may not be a smooth transition, because some OSes do not align partitions on 4K boundaries.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574196</id>
	<title>Re:Why are there sectors?</title>
	<author>will\_die</author>
	<datestamp>1262030400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>One thing the explanations are missing is that is this why if you bring up properties for a file on Windows XP, and others, you get two numbers.  The size of the file and the size on disk.</htmltext>
<tokenext>One thing the explanations are missing is that is this why if you bring up properties for a file on Windows XP , and others , you get two numbers .
The size of the file and the size on disk .</tokentext>
<sentencetext>One thing the explanations are missing is that is this why if you bring up properties for a file on Windows XP, and others, you get two numbers.
The size of the file and the size on disk.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578828</id>
	<title>Re:Factors of 10</title>
	<author>jonadab</author>
	<datestamp>1262018100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt; According to metric prefixes accepted in virtually<br>&gt; every other field, 4096 bytes is 4.1KB<br><br>In every other field, it's useful to know how many thousand of something you have.<br><br>In computing, however, it is a great deal more useful to know how many 1024-byte kilobytes you have, because space is allocated in power-of-two-sized sectors, so 1024 is either a multiple (two 512-byte sectors) or a factor (a quarter of a 4096-byte sector).<br><br>With a 512-byte sector, if I have a bunch of very small (but not zero-size) files and the disk has 128 kilobytes left, I expect to be able to store no more than 256 of my little files in that space.  But if some cretinous loser programs the shell to tell me that I have 131 metric "kilobytes", I won't know how much space I really have.<br><br>If you want to use metric quantities, use kilobits, megabits, gigabits, and so on (as, indeed, is commonly done when measuring bandwidth).  The byte is a power-of-two-based unit, which is what makes it useful for measuring computer storage, because computers do all their arithmetic in binary and for this reason are always going to allocate space (both in volatile memory and on secondary storage) in those terms.  It's that way for a reason, and it is going to stay that way.<br><br>You'll notice they're not talking about 4000-byte or 40000-bit sectors.  That would be dumb.</htmltext>
<tokenext>&gt; According to metric prefixes accepted in virtually &gt; every other field , 4096 bytes is 4.1KBIn every other field , it 's useful to know how many thousand of something you have.In computing , however , it is a great deal more useful to know how many 1024-byte kilobytes you have , because space is allocated in power-of-two-sized sectors , so 1024 is either a multiple ( two 512-byte sectors ) or a factor ( a quarter of a 4096-byte sector ) .With a 512-byte sector , if I have a bunch of very small ( but not zero-size ) files and the disk has 128 kilobytes left , I expect to be able to store no more than 256 of my little files in that space .
But if some cretinous loser programs the shell to tell me that I have 131 metric " kilobytes " , I wo n't know how much space I really have.If you want to use metric quantities , use kilobits , megabits , gigabits , and so on ( as , indeed , is commonly done when measuring bandwidth ) .
The byte is a power-of-two-based unit , which is what makes it useful for measuring computer storage , because computers do all their arithmetic in binary and for this reason are always going to allocate space ( both in volatile memory and on secondary storage ) in those terms .
It 's that way for a reason , and it is going to stay that way.You 'll notice they 're not talking about 4000-byte or 40000-bit sectors .
That would be dumb .</tokentext>
<sentencetext>&gt; According to metric prefixes accepted in virtually&gt; every other field, 4096 bytes is 4.1KBIn every other field, it's useful to know how many thousand of something you have.In computing, however, it is a great deal more useful to know how many 1024-byte kilobytes you have, because space is allocated in power-of-two-sized sectors, so 1024 is either a multiple (two 512-byte sectors) or a factor (a quarter of a 4096-byte sector).With a 512-byte sector, if I have a bunch of very small (but not zero-size) files and the disk has 128 kilobytes left, I expect to be able to store no more than 256 of my little files in that space.
But if some cretinous loser programs the shell to tell me that I have 131 metric "kilobytes", I won't know how much space I really have.If you want to use metric quantities, use kilobits, megabits, gigabits, and so on (as, indeed, is commonly done when measuring bandwidth).
The byte is a power-of-two-based unit, which is what makes it useful for measuring computer storage, because computers do all their arithmetic in binary and for this reason are always going to allocate space (both in volatile memory and on secondary storage) in those terms.
It's that way for a reason, and it is going to stay that way.You'll notice they're not talking about 4000-byte or 40000-bit sectors.
That would be dumb.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574098</id>
	<title>Re:disable ECC?</title>
	<author>Anonymous</author>
	<datestamp>1262029980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Stupid much? ZFS uses a "plain" checksum, which is something far inferior to ECC, how do you want to use one to replace the other?<br>Read every sector 100 times on average till you by chance get one without an error (not that this is probably optimistic).<br>Well, you could just start writing you data on paper, the performance will probably be better.</p></htmltext>
<tokenext>Stupid much ?
ZFS uses a " plain " checksum , which is something far inferior to ECC , how do you want to use one to replace the other ? Read every sector 100 times on average till you by chance get one without an error ( not that this is probably optimistic ) .Well , you could just start writing you data on paper , the performance will probably be better .</tokentext>
<sentencetext>Stupid much?
ZFS uses a "plain" checksum, which is something far inferior to ECC, how do you want to use one to replace the other?Read every sector 100 times on average till you by chance get one without an error (not that this is probably optimistic).Well, you could just start writing you data on paper, the performance will probably be better.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578772</id>
	<title>Re:Factors of 10</title>
	<author>jonadab</author>
	<datestamp>1262017200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt;  A byte can be 10 bits; it's an architecture-specific quantity.<br><br>Historically, yes, but not any time recently.  Not, for instance, since people started to write software that was portable enough to be compiled for different hardware architectures.  If you think codepages and endianness are bad, just *imagine* trying to port your software to an architecture with an exotic byte size!  No thanks.  Different word sizes and address BUS widths are bad enough.</htmltext>
<tokenext>&gt; A byte can be 10 bits ; it 's an architecture-specific quantity.Historically , yes , but not any time recently .
Not , for instance , since people started to write software that was portable enough to be compiled for different hardware architectures .
If you think codepages and endianness are bad , just * imagine * trying to port your software to an architecture with an exotic byte size !
No thanks .
Different word sizes and address BUS widths are bad enough .</tokentext>
<sentencetext>&gt;  A byte can be 10 bits; it's an architecture-specific quantity.Historically, yes, but not any time recently.
Not, for instance, since people started to write software that was portable enough to be compiled for different hardware architectures.
If you think codepages and endianness are bad, just *imagine* trying to port your software to an architecture with an exotic byte size!
No thanks.
Different word sizes and address BUS widths are bad enough.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571580</id>
	<title>intelligent interfaces</title>
	<author>Anonymous</author>
	<datestamp>1262018520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Why does the sector size presented by the interface have to reflect anything about the hardware? isn't this like the CHS/LBA conversion done under the hood? What about the ability to request a particular sector size, with the default being 512 bytes and the recommended amount being the hardware amount for optimisation purposes? Memories of 512 versus 2048 in the CD booting of older versions of VMS...</p></htmltext>
<tokenext>Why does the sector size presented by the interface have to reflect anything about the hardware ?
is n't this like the CHS/LBA conversion done under the hood ?
What about the ability to request a particular sector size , with the default being 512 bytes and the recommended amount being the hardware amount for optimisation purposes ?
Memories of 512 versus 2048 in the CD booting of older versions of VMS.. .</tokentext>
<sentencetext>Why does the sector size presented by the interface have to reflect anything about the hardware?
isn't this like the CHS/LBA conversion done under the hood?
What about the ability to request a particular sector size, with the default being 512 bytes and the recommended amount being the hardware amount for optimisation purposes?
Memories of 512 versus 2048 in the CD booting of older versions of VMS...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574292</id>
	<title>misalignment costs 3X</title>
	<author>Anonymous</author>
	<datestamp>1262030880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Back in the day I had an underperforming RAID-5 array from Data General.  When their 3rd-tier engineering support explained to us how to properly align disk partitions to the stripe size, we \_tripled\_ our disk performance.  This required, of course, a complete dump/restore cycle to tape, incurring significant downtime. Clueless XP users on 4096 byte drives are in for a world of hurt.</p></htmltext>
<tokenext>Back in the day I had an underperforming RAID-5 array from Data General .
When their 3rd-tier engineering support explained to us how to properly align disk partitions to the stripe size , we \ _tripled \ _ our disk performance .
This required , of course , a complete dump/restore cycle to tape , incurring significant downtime .
Clueless XP users on 4096 byte drives are in for a world of hurt .</tokentext>
<sentencetext>Back in the day I had an underperforming RAID-5 array from Data General.
When their 3rd-tier engineering support explained to us how to properly align disk partitions to the stripe size, we \_tripled\_ our disk performance.
This required, of course, a complete dump/restore cycle to tape, incurring significant downtime.
Clueless XP users on 4096 byte drives are in for a world of hurt.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776</id>
	<title>Why are there sectors?</title>
	<author>AP31R0N</author>
	<datestamp>1262019480000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>i'm asking because i don't know, not to troll.</p><p>What is their purpose?  Does the purpose still matter?</p></htmltext>
<tokenext>i 'm asking because i do n't know , not to troll.What is their purpose ?
Does the purpose still matter ?</tokentext>
<sentencetext>i'm asking because i don't know, not to troll.What is their purpose?
Does the purpose still matter?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571708</id>
	<title>Re:intelligent interfaces</title>
	<author>tepples</author>
	<datestamp>1262019120000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>Why does the sector size presented by the interface have to reflect anything about the hardware?</p></div><p>If the OS clusters aren't aligned to physical sectors, the hard drive's controller has to read-modify-write all the time.</p></div>
	</htmltext>
<tokenext>Why does the sector size presented by the interface have to reflect anything about the hardware ? If the OS clusters are n't aligned to physical sectors , the hard drive 's controller has to read-modify-write all the time .</tokentext>
<sentencetext>Why does the sector size presented by the interface have to reflect anything about the hardware?If the OS clusters aren't aligned to physical sectors, the hard drive's controller has to read-modify-write all the time.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571580</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571532</id>
	<title>Care to provide examples?</title>
	<author>bogaboga</author>
	<datestamp>1262018280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>"...This may not be a smooth transition, because some OSes do not align partitions on 4K boundaries..."</p></div><p>In cases like these, it always helps to provide examples.  Care to do so? Thanks.</p></div>
	</htmltext>
<tokenext>" ...This may not be a smooth transition , because some OSes do not align partitions on 4K boundaries... " In cases like these , it always helps to provide examples .
Care to do so ?
Thanks .</tokentext>
<sentencetext>"...This may not be a smooth transition, because some OSes do not align partitions on 4K boundaries..."In cases like these, it always helps to provide examples.
Care to do so?
Thanks.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578664</id>
	<title>Re:Moot Point</title>
	<author>drsmithy</author>
	<datestamp>1262016060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p> <i>The point is going to be Moot here really shortly. The whole idea of sectoring and block sizes and such is going to go the way of the DODO in a few short years as we move from Magnetic Media to Solid State.</i>
</p><p>I don't know what you consider "short" in this context, but current methods of addressing storage sure as hell aren't going anywhere for at least the next 15 years, and more likely 25.
</p><p> <i>We're already starting to see the end of Magnetic Media. I would suspect that in 4 or 5 years, magnetic drives will be mostly gone.</i>
</p><p>Not going to happen.  10-15 years, maybe.  SSDs just aren't going to increase in $/GB fast enough for a shorter timeframe to be practical.  A "cheap" 500GB SSD costs $1700ish today.  A 2TB drive costs $150ish.
</p><p>Another example: contemporary SANs are still primarily magnetic disk, and that certainly doesn't look to be changing any time soon (ie: within 18 months).  Any SAN investment of significance will be used for *at least* 3-5 years after purchase.</p></htmltext>
<tokenext>The point is going to be Moot here really shortly .
The whole idea of sectoring and block sizes and such is going to go the way of the DODO in a few short years as we move from Magnetic Media to Solid State .
I do n't know what you consider " short " in this context , but current methods of addressing storage sure as hell are n't going anywhere for at least the next 15 years , and more likely 25 .
We 're already starting to see the end of Magnetic Media .
I would suspect that in 4 or 5 years , magnetic drives will be mostly gone .
Not going to happen .
10-15 years , maybe .
SSDs just are n't going to increase in $ /GB fast enough for a shorter timeframe to be practical .
A " cheap " 500GB SSD costs $ 1700ish today .
A 2TB drive costs $ 150ish .
Another example : contemporary SANs are still primarily magnetic disk , and that certainly does n't look to be changing any time soon ( ie : within 18 months ) .
Any SAN investment of significance will be used for * at least * 3-5 years after purchase .</tokentext>
<sentencetext> The point is going to be Moot here really shortly.
The whole idea of sectoring and block sizes and such is going to go the way of the DODO in a few short years as we move from Magnetic Media to Solid State.
I don't know what you consider "short" in this context, but current methods of addressing storage sure as hell aren't going anywhere for at least the next 15 years, and more likely 25.
We're already starting to see the end of Magnetic Media.
I would suspect that in 4 or 5 years, magnetic drives will be mostly gone.
Not going to happen.
10-15 years, maybe.
SSDs just aren't going to increase in $/GB fast enough for a shorter timeframe to be practical.
A "cheap" 500GB SSD costs $1700ish today.
A 2TB drive costs $150ish.
Another example: contemporary SANs are still primarily magnetic disk, and that certainly doesn't look to be changing any time soon (ie: within 18 months).
Any SAN investment of significance will be used for *at least* 3-5 years after purchase.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571486</id>
	<title>So only XP is out of luck?</title>
	<author>Anonymous</author>
	<datestamp>1262017980000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext>According to the Anandtech article, only the pretty much end-of-life Windows XP is out of luck.

Linux, OS X and modern Windows versions all work<nobr> <wbr></nobr>...

Non news?</htmltext>
<tokenext>According to the Anandtech article , only the pretty much end-of-life Windows XP is out of luck .
Linux , OS X and modern Windows versions all work .. . Non news ?</tokentext>
<sentencetext>According to the Anandtech article, only the pretty much end-of-life Windows XP is out of luck.
Linux, OS X and modern Windows versions all work ...

Non news?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30601540</id>
	<title>Re:Factors of 10</title>
	<author>BikeHelmet</author>
	<datestamp>1259848200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It appears I'm a troll and you're insightful, because more slashdotters agree with you.</p><p>Of course, you're incorrect.</p><p>I hate quoting wikipedia, but...</p><p><a href="http://en.wikipedia.org/wiki/Binary\_prefix#Files" title="wikipedia.org">http://en.wikipedia.org/wiki/Binary\_prefix#Files</a> [wikipedia.org]<br><a href="http://en.wikipedia.org/wiki/Binary\_prefix#Hard\_disk\_drives" title="wikipedia.org">http://en.wikipedia.org/wiki/Binary\_prefix#Hard\_disk\_drives</a> [wikipedia.org]</p><p>I can't find any evidence of this:</p><p><div class="quote"><p>but back when hard disk manufactures realised they could make their hard disks look bigger than they really were</p></div><p>All the evidence I've found (including on other sites) says it was always measured in metric. At some point IBM switched to 512b block sizes just because. They could've just as easily went with 500b block sizes, except they didn't, and 512b stuck.</p><p>How that translates into some nefarious marketing fiasco is beyond me.</p><p><div class="quote"><p> <b>*all*</b> OSes were using power-of-two prefixes.</p></div><p>Could you please prove that?</p><p>Because I remember hearing that *one* OS did it properly, and it was one of the early ones. Now if only I could find the link.</p></div>
	</htmltext>
<tokenext>It appears I 'm a troll and you 're insightful , because more slashdotters agree with you.Of course , you 're incorrect.I hate quoting wikipedia , but...http : //en.wikipedia.org/wiki/Binary \ _prefix # Files [ wikipedia.org ] http : //en.wikipedia.org/wiki/Binary \ _prefix # Hard \ _disk \ _drives [ wikipedia.org ] I ca n't find any evidence of this : but back when hard disk manufactures realised they could make their hard disks look bigger than they really wereAll the evidence I 've found ( including on other sites ) says it was always measured in metric .
At some point IBM switched to 512b block sizes just because .
They could 've just as easily went with 500b block sizes , except they did n't , and 512b stuck.How that translates into some nefarious marketing fiasco is beyond me .
* all * OSes were using power-of-two prefixes.Could you please prove that ? Because I remember hearing that * one * OS did it properly , and it was one of the early ones .
Now if only I could find the link .</tokentext>
<sentencetext>It appears I'm a troll and you're insightful, because more slashdotters agree with you.Of course, you're incorrect.I hate quoting wikipedia, but...http://en.wikipedia.org/wiki/Binary\_prefix#Files [wikipedia.org]http://en.wikipedia.org/wiki/Binary\_prefix#Hard\_disk\_drives [wikipedia.org]I can't find any evidence of this:but back when hard disk manufactures realised they could make their hard disks look bigger than they really wereAll the evidence I've found (including on other sites) says it was always measured in metric.
At some point IBM switched to 512b block sizes just because.
They could've just as easily went with 500b block sizes, except they didn't, and 512b stuck.How that translates into some nefarious marketing fiasco is beyond me.
*all* OSes were using power-of-two prefixes.Could you please prove that?Because I remember hearing that *one* OS did it properly, and it was one of the early ones.
Now if only I could find the link.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572162</id>
	<title>Re:disable ECC?</title>
	<author>Waffle Iron</author>
	<datestamp>1262021460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>It doesn't seem like a great idea to me. There are a lot of different ECC algorithms and implementations. It seems to me that it would be better to let the hard drive manufacturer select one that closely matches the expected signal and noise characteristics of a particular disk drive rather than some generic algorithm in the filesystem.</p></htmltext>
<tokenext>It does n't seem like a great idea to me .
There are a lot of different ECC algorithms and implementations .
It seems to me that it would be better to let the hard drive manufacturer select one that closely matches the expected signal and noise characteristics of a particular disk drive rather than some generic algorithm in the filesystem .</tokentext>
<sentencetext>It doesn't seem like a great idea to me.
There are a lot of different ECC algorithms and implementations.
It seems to me that it would be better to let the hard drive manufacturer select one that closely matches the expected signal and noise characteristics of a particular disk drive rather than some generic algorithm in the filesystem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573006</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262024880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Wrong.<br>A word is architecture specific.<br>A byte is ALWAYS 8 bits.</p></htmltext>
<tokenext>Wrong.A word is architecture specific.A byte is ALWAYS 8 bits .</tokentext>
<sentencetext>Wrong.A word is architecture specific.A byte is ALWAYS 8 bits.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346</id>
	<title>Re:Factors of 10</title>
	<author>BikeHelmet</author>
	<datestamp>1261998240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>4096 byte sectors are fine. It's nice that we'll get roughly 10\% more usable space for no cost.</p><p>But I think it'd be nice if when I open a 4KiB file it said 4KiB. According to metric prefixes accepted in virtually every other field, 4096 bytes is 4.1KB (or 4.096KB to be exact) Being "digital" does not give the right to use the wrong prefixes and cause confusion.</p><p>It's also worth noting that this is Microsoft's fault. Other OS's are doing it properly. Microsoft only does it properly when it benefits them. HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix, so people feel cheated out of space. And the issue will only get worse... Every time we jump from one incorrect prefix to another.</p><p>1024 bytes - 1KiB - 2.4\% discrepancy.<br>1048,576 bytes - 1MiB - 4.85\% discrepancy<br>1073,741,824 bytes - GiB - 7.37\% discrepancy<br>1099,511,627,776 bytes - 1TiB - 9.95\% discrepancy</p><p>When you buy a 1500,000,000,000 byte HDD (which includes free error checking bits, so really has over 1650,000,000,000 bytes - 1.5TB usable), Windows reports the capacity as 1.36TB (incorrect) - not 1.36TiB. (correct)</p><p>Can't wait for the new round of lawsuits when we hit petabytes - 1125,899,906,842,624 bytes, a 12.6\% discrepancy. And the ridiculousness of this is, it's not even a real issue.</p><p>Why aren't we suing SSD manufacturers? They often give us less bytes than advertised in both metric and incorrect metric.</p><p>Does nobody care about filesystem overhead? We lose as much as 20\% of our disk capacity to shitty filesystems. That's way more than the Metric debate.</p><p>What about disk performance? It's harder to measure, but doesn't I/O performance matter more than capacity? Sun proved you can design a FS that doesn't lose significant performance or require defragmenting - ZFS. Microsoft with their NTFS is probably costing us 30\% I/O performance. Wouldn't it be nice to have Reiser4 available for servers or computers with UPS's?</p><p>As long as we remain fixated on something that isn't an actual issue, we'll never correct the ones that are.</p></htmltext>
<tokenext>4096 byte sectors are fine .
It 's nice that we 'll get roughly 10 \ % more usable space for no cost.But I think it 'd be nice if when I open a 4KiB file it said 4KiB .
According to metric prefixes accepted in virtually every other field , 4096 bytes is 4.1KB ( or 4.096KB to be exact ) Being " digital " does not give the right to use the wrong prefixes and cause confusion.It 's also worth noting that this is Microsoft 's fault .
Other OS 's are doing it properly .
Microsoft only does it properly when it benefits them .
HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix , so people feel cheated out of space .
And the issue will only get worse... Every time we jump from one incorrect prefix to another.1024 bytes - 1KiB - 2.4 \ % discrepancy.1048,576 bytes - 1MiB - 4.85 \ % discrepancy1073,741,824 bytes - GiB - 7.37 \ % discrepancy1099,511,627,776 bytes - 1TiB - 9.95 \ % discrepancyWhen you buy a 1500,000,000,000 byte HDD ( which includes free error checking bits , so really has over 1650,000,000,000 bytes - 1.5TB usable ) , Windows reports the capacity as 1.36TB ( incorrect ) - not 1.36TiB .
( correct ) Ca n't wait for the new round of lawsuits when we hit petabytes - 1125,899,906,842,624 bytes , a 12.6 \ % discrepancy .
And the ridiculousness of this is , it 's not even a real issue.Why are n't we suing SSD manufacturers ?
They often give us less bytes than advertised in both metric and incorrect metric.Does nobody care about filesystem overhead ?
We lose as much as 20 \ % of our disk capacity to shitty filesystems .
That 's way more than the Metric debate.What about disk performance ?
It 's harder to measure , but does n't I/O performance matter more than capacity ?
Sun proved you can design a FS that does n't lose significant performance or require defragmenting - ZFS .
Microsoft with their NTFS is probably costing us 30 \ % I/O performance .
Would n't it be nice to have Reiser4 available for servers or computers with UPS 's ? As long as we remain fixated on something that is n't an actual issue , we 'll never correct the ones that are .</tokentext>
<sentencetext>4096 byte sectors are fine.
It's nice that we'll get roughly 10\% more usable space for no cost.But I think it'd be nice if when I open a 4KiB file it said 4KiB.
According to metric prefixes accepted in virtually every other field, 4096 bytes is 4.1KB (or 4.096KB to be exact) Being "digital" does not give the right to use the wrong prefixes and cause confusion.It's also worth noting that this is Microsoft's fault.
Other OS's are doing it properly.
Microsoft only does it properly when it benefits them.
HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix, so people feel cheated out of space.
And the issue will only get worse... Every time we jump from one incorrect prefix to another.1024 bytes - 1KiB - 2.4\% discrepancy.1048,576 bytes - 1MiB - 4.85\% discrepancy1073,741,824 bytes - GiB - 7.37\% discrepancy1099,511,627,776 bytes - 1TiB - 9.95\% discrepancyWhen you buy a 1500,000,000,000 byte HDD (which includes free error checking bits, so really has over 1650,000,000,000 bytes - 1.5TB usable), Windows reports the capacity as 1.36TB (incorrect) - not 1.36TiB.
(correct)Can't wait for the new round of lawsuits when we hit petabytes - 1125,899,906,842,624 bytes, a 12.6\% discrepancy.
And the ridiculousness of this is, it's not even a real issue.Why aren't we suing SSD manufacturers?
They often give us less bytes than advertised in both metric and incorrect metric.Does nobody care about filesystem overhead?
We lose as much as 20\% of our disk capacity to shitty filesystems.
That's way more than the Metric debate.What about disk performance?
It's harder to measure, but doesn't I/O performance matter more than capacity?
Sun proved you can design a FS that doesn't lose significant performance or require defragmenting - ZFS.
Microsoft with their NTFS is probably costing us 30\% I/O performance.
Wouldn't it be nice to have Reiser4 available for servers or computers with UPS's?As long as we remain fixated on something that isn't an actual issue, we'll never correct the ones that are.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573762</id>
	<title>Well it's about time that they caught up</title>
	<author>sloepoke51</author>
	<datestamp>1262028300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Back in the late 70's there was a new OS, CP/M 80 Version 2.  Included in the BIOS support was a simple and very effctive sector blocking / Deblocking algorithm.  The default support was 128 byte sectors on the common disk environment, 8 inch floppy disks.  With the sector blocking and deblocking code, any size of physical sectors could be supported.  On my Morrow Thinker Toy's double density controller, I was able to go from 256 byte sectors to 1024 byte sectors gaining a nice huck of space.  In 1981 I worked for Micromation and had a chance to play with a 14 inch winchester hard drive, which had a huge 20 megabyte capacity.  It had a "fixed" 512 byte sector size.  After a little messing around with the drive, I found that the drive really could support larger physical sectors.  I went from the 20 megabyte tot disk size to 1024 byte sectors and go another 6 megabytes for a total 26 MB out  of a 20 MB drive just by enlarging the sector size.</htmltext>
<tokenext>Back in the late 70 's there was a new OS , CP/M 80 Version 2 .
Included in the BIOS support was a simple and very effctive sector blocking / Deblocking algorithm .
The default support was 128 byte sectors on the common disk environment , 8 inch floppy disks .
With the sector blocking and deblocking code , any size of physical sectors could be supported .
On my Morrow Thinker Toy 's double density controller , I was able to go from 256 byte sectors to 1024 byte sectors gaining a nice huck of space .
In 1981 I worked for Micromation and had a chance to play with a 14 inch winchester hard drive , which had a huge 20 megabyte capacity .
It had a " fixed " 512 byte sector size .
After a little messing around with the drive , I found that the drive really could support larger physical sectors .
I went from the 20 megabyte tot disk size to 1024 byte sectors and go another 6 megabytes for a total 26 MB out of a 20 MB drive just by enlarging the sector size .</tokentext>
<sentencetext>Back in the late 70's there was a new OS, CP/M 80 Version 2.
Included in the BIOS support was a simple and very effctive sector blocking / Deblocking algorithm.
The default support was 128 byte sectors on the common disk environment, 8 inch floppy disks.
With the sector blocking and deblocking code, any size of physical sectors could be supported.
On my Morrow Thinker Toy's double density controller, I was able to go from 256 byte sectors to 1024 byte sectors gaining a nice huck of space.
In 1981 I worked for Micromation and had a chance to play with a 14 inch winchester hard drive, which had a huge 20 megabyte capacity.
It had a "fixed" 512 byte sector size.
After a little messing around with the drive, I found that the drive really could support larger physical sectors.
I went from the 20 megabyte tot disk size to 1024 byte sectors and go another 6 megabytes for a total 26 MB out  of a 20 MB drive just by enlarging the sector size.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572226</id>
	<title>Re:Isn't this just a firmware change?</title>
	<author>Anonymous</author>
	<datestamp>1262021700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>It doesn't sound like the 512 bytes per sector is tightly bound to hardware.</p></div><p>The hardware is fundamentally designed to work optimally for whatever data unit, (sector, PDU, packet, whatever) is specified.  There are buffers (physical memory, very fast, not general purpose) sized precisely for the packets.  The time required to modulate the contents of the buffers across the bus(ses) is a function of the packet size and bus frequency; i.e. it does not vary and is therefore assumed throughout the system.  This is real low level stuff we're talking about.  The chips on the bottom of your disks are not general purpose devices that change their nature because you recompile something.</p><p><div class="quote"><p>If your business depends on WinXP so much</p></div><p>Heh.  I think it's the other way around.  NTFS has been 4K aligned for a long time now; there are actually tools in the world to align legacy FAT file systems to 4K for conversion purposes.  The phrase "some OSs" instead of "micro$oft" is a subtle clue that it's actually the non-microsoft systems that will have 4K unaligned partitions.  You were expected to detect that.</p></div>
	</htmltext>
<tokenext>It does n't sound like the 512 bytes per sector is tightly bound to hardware.The hardware is fundamentally designed to work optimally for whatever data unit , ( sector , PDU , packet , whatever ) is specified .
There are buffers ( physical memory , very fast , not general purpose ) sized precisely for the packets .
The time required to modulate the contents of the buffers across the bus ( ses ) is a function of the packet size and bus frequency ; i.e .
it does not vary and is therefore assumed throughout the system .
This is real low level stuff we 're talking about .
The chips on the bottom of your disks are not general purpose devices that change their nature because you recompile something.If your business depends on WinXP so muchHeh .
I think it 's the other way around .
NTFS has been 4K aligned for a long time now ; there are actually tools in the world to align legacy FAT file systems to 4K for conversion purposes .
The phrase " some OSs " instead of " micro $ oft " is a subtle clue that it 's actually the non-microsoft systems that will have 4K unaligned partitions .
You were expected to detect that .</tokentext>
<sentencetext>It doesn't sound like the 512 bytes per sector is tightly bound to hardware.The hardware is fundamentally designed to work optimally for whatever data unit, (sector, PDU, packet, whatever) is specified.
There are buffers (physical memory, very fast, not general purpose) sized precisely for the packets.
The time required to modulate the contents of the buffers across the bus(ses) is a function of the packet size and bus frequency; i.e.
it does not vary and is therefore assumed throughout the system.
This is real low level stuff we're talking about.
The chips on the bottom of your disks are not general purpose devices that change their nature because you recompile something.If your business depends on WinXP so muchHeh.
I think it's the other way around.
NTFS has been 4K aligned for a long time now; there are actually tools in the world to align legacy FAT file systems to 4K for conversion purposes.
The phrase "some OSs" instead of "micro$oft" is a subtle clue that it's actually the non-microsoft systems that will have 4K unaligned partitions.
You were expected to detect that.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573978</id>
	<title>Re:Care to provide examples?</title>
	<author>Anonymous</author>
	<datestamp>1262029380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's not that other OSes aren't affected but that there's not enough of a usebase for the affected versions that anyone cares.</p><p>From the AnandTech article:</p><blockquote><div><p>Notably, Linux and Mac OS X are not affected by this issue. Western Digital has tested both of these operating systems, and officially classifies them as not-affected. Ultimately we suspect that if you went back far enough you could find older versions of these OSes that are affected, but unlike Win 5.xx, there&rsquo;s not a significant legacy user base to worry about.</p></div> </blockquote></div>
	</htmltext>
<tokenext>It 's not that other OSes are n't affected but that there 's not enough of a usebase for the affected versions that anyone cares.From the AnandTech article : Notably , Linux and Mac OS X are not affected by this issue .
Western Digital has tested both of these operating systems , and officially classifies them as not-affected .
Ultimately we suspect that if you went back far enough you could find older versions of these OSes that are affected , but unlike Win 5.xx , there    s not a significant legacy user base to worry about .</tokentext>
<sentencetext>It's not that other OSes aren't affected but that there's not enough of a usebase for the affected versions that anyone cares.From the AnandTech article:Notably, Linux and Mac OS X are not affected by this issue.
Western Digital has tested both of these operating systems, and officially classifies them as not-affected.
Ultimately we suspect that if you went back far enough you could find older versions of these OSes that are affected, but unlike Win 5.xx, there’s not a significant legacy user base to worry about. 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572908</id>
	<title>Re:Paying for More Slack Space</title>
	<author>PhrstBrn</author>
	<datestamp>1262024400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When they're able to make disks ~10\% bigger just by switching to the larger sector size, I couldn't care less about this "wasted" space.

You have a 1TB drive.  Because of this change, they can fit 1.1TB of data onto the same size platter.  So it would take ~28 million files worst-case scenario in this hypothetical situation before the 1.1TB drive would have less usable space.

Of course, they like nice round numbers, so what it really means is they can make drives cheaper and faster.  In the long run the consumer will win (there is enough competition where you shouldn't need to worry about price fixing).  I like it.</htmltext>
<tokenext>When they 're able to make disks ~ 10 \ % bigger just by switching to the larger sector size , I could n't care less about this " wasted " space .
You have a 1TB drive .
Because of this change , they can fit 1.1TB of data onto the same size platter .
So it would take ~ 28 million files worst-case scenario in this hypothetical situation before the 1.1TB drive would have less usable space .
Of course , they like nice round numbers , so what it really means is they can make drives cheaper and faster .
In the long run the consumer will win ( there is enough competition where you should n't need to worry about price fixing ) .
I like it .</tokentext>
<sentencetext>When they're able to make disks ~10\% bigger just by switching to the larger sector size, I couldn't care less about this "wasted" space.
You have a 1TB drive.
Because of this change, they can fit 1.1TB of data onto the same size platter.
So it would take ~28 million files worst-case scenario in this hypothetical situation before the 1.1TB drive would have less usable space.
Of course, they like nice round numbers, so what it really means is they can make drives cheaper and faster.
In the long run the consumer will win (there is enough competition where you shouldn't need to worry about price fixing).
I like it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572478</id>
	<title>Re:Paying for More Slack Space</title>
	<author>644bd346996</author>
	<datestamp>1262022780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Except that larger sectors also means more efficient ECC, so the same drive will present a higher OS-accessible capacity. Unless you plan to deal mostly in files that are less than 4K, you'll come out ahead.</p></htmltext>
<tokenext>Except that larger sectors also means more efficient ECC , so the same drive will present a higher OS-accessible capacity .
Unless you plan to deal mostly in files that are less than 4K , you 'll come out ahead .</tokentext>
<sentencetext>Except that larger sectors also means more efficient ECC, so the same drive will present a higher OS-accessible capacity.
Unless you plan to deal mostly in files that are less than 4K, you'll come out ahead.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262018160000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>1</modscore>
	<htmltext><p>If they want to use base10 the first thing they should do is respecify a byte to be 10bits.</p><p>I somehow think their enthusiasm for base10 would diminish when it would case a a 25\% drop in stated capacity.</p></htmltext>
<tokenext>If they want to use base10 the first thing they should do is respecify a byte to be 10bits.I somehow think their enthusiasm for base10 would diminish when it would case a a 25 \ % drop in stated capacity .</tokentext>
<sentencetext>If they want to use base10 the first thing they should do is respecify a byte to be 10bits.I somehow think their enthusiasm for base10 would diminish when it would case a a 25\% drop in stated capacity.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572468</id>
	<title>Re:disable ECC?</title>
	<author>Izmunuti</author>
	<datestamp>1262022720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Ugh.  Sounds like a bad idea. Hard drive channels are noisy.  How will ZFS fare if lots and lots of sectors read from every drive have at least a couple of bits in error?  With no ECC in the drive, errors would be common.</p></htmltext>
<tokenext>Ugh .
Sounds like a bad idea .
Hard drive channels are noisy .
How will ZFS fare if lots and lots of sectors read from every drive have at least a couple of bits in error ?
With no ECC in the drive , errors would be common .</tokentext>
<sentencetext>Ugh.
Sounds like a bad idea.
Hard drive channels are noisy.
How will ZFS fare if lots and lots of sectors read from every drive have at least a couple of bits in error?
With no ECC in the drive, errors would be common.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258</id>
	<title>Paying for More Slack Space</title>
	<author>Anonymous</author>
	<datestamp>1262021820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Larger sectors means more empty space at the end of the last sector of a file. Lots of files means lots of wasted space. Modern OS'es, especially Windows, have many more, smaller files than in past versions, and the trend continues upwards.</p><p>So larger sectors means more space bought on a drive that isn't used. Which means more drives bought.</p><p>I can see how drive manufacturers would like that.</p></htmltext>
<tokenext>Larger sectors means more empty space at the end of the last sector of a file .
Lots of files means lots of wasted space .
Modern OS'es , especially Windows , have many more , smaller files than in past versions , and the trend continues upwards.So larger sectors means more space bought on a drive that is n't used .
Which means more drives bought.I can see how drive manufacturers would like that .</tokentext>
<sentencetext>Larger sectors means more empty space at the end of the last sector of a file.
Lots of files means lots of wasted space.
Modern OS'es, especially Windows, have many more, smaller files than in past versions, and the trend continues upwards.So larger sectors means more space bought on a drive that isn't used.
Which means more drives bought.I can see how drive manufacturers would like that.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571818</id>
	<title>use of current cultural context....</title>
	<author>Himring</author>
	<datestamp>1262019660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><i>This may not be a smooth transition, because some OSes do not align partitions on 4K boundaries.</i>
<br> <br>
"One life ends; another begins"</htmltext>
<tokenext>This may not be a smooth transition , because some OSes do not align partitions on 4K boundaries .
" One life ends ; another begins "</tokentext>
<sentencetext>This may not be a smooth transition, because some OSes do not align partitions on 4K boundaries.
"One life ends; another begins"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572244</id>
	<title>Re:Care to provide examples?</title>
	<author>Anonymous</author>
	<datestamp>1262021760000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>It took me longer than it should've to answer this riddle. Shortcut for the similarly caffeine deprived: andrewd18 means "P" as in Windows XP.</p><p>Seriously, I was like "Win...dows?" "U...nix?" "Micro...soft?" "OS...X"? "BS...D"?</p></htmltext>
<tokenext>It took me longer than it should 've to answer this riddle .
Shortcut for the similarly caffeine deprived : andrewd18 means " P " as in Windows XP.Seriously , I was like " Win...dows ?
" " U...nix ?
" " Micro...soft ?
" " OS...X " ?
" BS...D " ?</tokentext>
<sentencetext>It took me longer than it should've to answer this riddle.
Shortcut for the similarly caffeine deprived: andrewd18 means "P" as in Windows XP.Seriously, I was like "Win...dows?
" "U...nix?
" "Micro...soft?
" "OS...X"?
"BS...D"?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572674</id>
	<title>Re:disable ECC?</title>
	<author>Anonymous</author>
	<datestamp>1262023500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>An ECC should be implemented as close to where the problem occurs as possible. For a hard drive, this means on sectors, not (abstract) blocks. Otherwise you'll see the OS rewriting clean sectors that are parts of unclean blocks (if the block size is greater than the sector size), and gain nothing if the block size is smaller than the sector size.</p></htmltext>
<tokenext>An ECC should be implemented as close to where the problem occurs as possible .
For a hard drive , this means on sectors , not ( abstract ) blocks .
Otherwise you 'll see the OS rewriting clean sectors that are parts of unclean blocks ( if the block size is greater than the sector size ) , and gain nothing if the block size is smaller than the sector size .</tokentext>
<sentencetext>An ECC should be implemented as close to where the problem occurs as possible.
For a hard drive, this means on sectors, not (abstract) blocks.
Otherwise you'll see the OS rewriting clean sectors that are parts of unclean blocks (if the block size is greater than the sector size), and gain nothing if the block size is smaller than the sector size.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572444</id>
	<title>Okay. So, what if we have to image an old box?</title>
	<author>E-Sabbath</author>
	<datestamp>1262022600000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>Let's say, two situations.<br>A: Moving an XP box from an old 512 sector drive to a new, 4k sector drive. Image using, say, Acronis. Just have to run the CLI tool, after imaging?</p><p>B: Moving an XP box, using Acronis, from a 4k to a 4k. Would I have to run the tool?</p></htmltext>
<tokenext>Let 's say , two situations.A : Moving an XP box from an old 512 sector drive to a new , 4k sector drive .
Image using , say , Acronis .
Just have to run the CLI tool , after imaging ? B : Moving an XP box , using Acronis , from a 4k to a 4k .
Would I have to run the tool ?</tokentext>
<sentencetext>Let's say, two situations.A: Moving an XP box from an old 512 sector drive to a new, 4k sector drive.
Image using, say, Acronis.
Just have to run the CLI tool, after imaging?B: Moving an XP box, using Acronis, from a 4k to a 4k.
Would I have to run the tool?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572184</id>
	<title>WD's technical whitepaper</title>
	<author>cjjjer</author>
	<datestamp>1262021520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><a href="http://www.wdc.com/wdproducts/library/whitepapers/en/2579-771430.pdf" title="wdc.com" rel="nofollow">http://www.wdc.com/wdproducts/library/whitepapers/en/2579-771430.pdf</a> [wdc.com]</htmltext>
<tokenext>http : //www.wdc.com/wdproducts/library/whitepapers/en/2579-771430.pdf [ wdc.com ]</tokentext>
<sentencetext>http://www.wdc.com/wdproducts/library/whitepapers/en/2579-771430.pdf [wdc.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</id>
	<title>disable ECC?</title>
	<author>Anonymous</author>
	<datestamp>1262019240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>I heard some talks from the ZFS folks at Sun about how they were floating the idea to HD mfgr's of just disabling ECC on the drives. ZFS checksums every block, and in a RAID configuration, it would be able to transparently correct any checksum errors. I think this may have also been the motivation behind bringing triple-redundant RAID to ZFS.</p><p>The motivating idea was that this would reduce the overhead involved on ECC and gain extra space.</p><p>Thoughts?</p></htmltext>
<tokenext>I heard some talks from the ZFS folks at Sun about how they were floating the idea to HD mfgr 's of just disabling ECC on the drives .
ZFS checksums every block , and in a RAID configuration , it would be able to transparently correct any checksum errors .
I think this may have also been the motivation behind bringing triple-redundant RAID to ZFS.The motivating idea was that this would reduce the overhead involved on ECC and gain extra space.Thoughts ?</tokentext>
<sentencetext>I heard some talks from the ZFS folks at Sun about how they were floating the idea to HD mfgr's of just disabling ECC on the drives.
ZFS checksums every block, and in a RAID configuration, it would be able to transparently correct any checksum errors.
I think this may have also been the motivation behind bringing triple-redundant RAID to ZFS.The motivating idea was that this would reduce the overhead involved on ECC and gain extra space.Thoughts?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577284</id>
	<title>Re:Time to Eliminate this problem</title>
	<author>the\_enigma\_1983</author>
	<datestamp>1262004780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>From the sounds of it, you're recommending that we move all file system operations over to the HDD (all of the managing where files are, how big they are, what directories exist etc)?</htmltext>
<tokenext>From the sounds of it , you 're recommending that we move all file system operations over to the HDD ( all of the managing where files are , how big they are , what directories exist etc ) ?</tokentext>
<sentencetext>From the sounds of it, you're recommending that we move all file system operations over to the HDD (all of the managing where files are, how big they are, what directories exist etc)?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574414</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574704</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262032920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Its not thought. Its smacks of societies rampant idiotcy.</p></htmltext>
<tokenext>Its not thought .
Its smacks of societies rampant idiotcy .</tokentext>
<sentencetext>Its not thought.
Its smacks of societies rampant idiotcy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666</id>
	<title>Isn't this  just a firmware change?</title>
	<author>Anonymous</author>
	<datestamp>1262018940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>It doesn't sound like the 512 bytes per sector is tightly bound to hardware. More like a low-level reformat plus change of some #defines in the firmware to transform from one to another type. Which would mean there could be i.e. a jumper setting for sector size, allowing for backward compatibility.</p><p>Also, the fact an OS doesn't enforce partition alignment doesn't mean it won't respect a disk formatted to aligned partitions. Just provide a 3rd party partitioning tool that aligns the partitions right, and install the OS on pre-made partitions. If your business depends on WinXP so much, your IT dept should be capable of doing it.</p></htmltext>
<tokenext>It does n't sound like the 512 bytes per sector is tightly bound to hardware .
More like a low-level reformat plus change of some # defines in the firmware to transform from one to another type .
Which would mean there could be i.e .
a jumper setting for sector size , allowing for backward compatibility.Also , the fact an OS does n't enforce partition alignment does n't mean it wo n't respect a disk formatted to aligned partitions .
Just provide a 3rd party partitioning tool that aligns the partitions right , and install the OS on pre-made partitions .
If your business depends on WinXP so much , your IT dept should be capable of doing it .</tokentext>
<sentencetext>It doesn't sound like the 512 bytes per sector is tightly bound to hardware.
More like a low-level reformat plus change of some #defines in the firmware to transform from one to another type.
Which would mean there could be i.e.
a jumper setting for sector size, allowing for backward compatibility.Also, the fact an OS doesn't enforce partition alignment doesn't mean it won't respect a disk formatted to aligned partitions.
Just provide a 3rd party partitioning tool that aligns the partitions right, and install the OS on pre-made partitions.
If your business depends on WinXP so much, your IT dept should be capable of doing it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572306</id>
	<title>Re:Why are there sectors?</title>
	<author>Izmunuti</author>
	<datestamp>1262022060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Hard drives are random-access devices and sectors are the smallest atomic unit that a drive can normally physically read and write.  It doesn't read or write half a sector.  When emulating a write to a 512 byte logical block with 4096 byte physical blocks on the media, it has to read the whole 4K sector, modify it with the changed 512 bytes, and rewrite the entire 4K sector.</p><p>The concept of sectors could be hidden from the interface, theoretically. You could put the whole file system into the drive (OSD), for example, or allow the host to address bytes, hiding all the read/modify/writes.  But, all the common hard drive interfaces (ATA/SCSI) use blocks/sectors.</p></htmltext>
<tokenext>Hard drives are random-access devices and sectors are the smallest atomic unit that a drive can normally physically read and write .
It does n't read or write half a sector .
When emulating a write to a 512 byte logical block with 4096 byte physical blocks on the media , it has to read the whole 4K sector , modify it with the changed 512 bytes , and rewrite the entire 4K sector.The concept of sectors could be hidden from the interface , theoretically .
You could put the whole file system into the drive ( OSD ) , for example , or allow the host to address bytes , hiding all the read/modify/writes .
But , all the common hard drive interfaces ( ATA/SCSI ) use blocks/sectors .</tokentext>
<sentencetext>Hard drives are random-access devices and sectors are the smallest atomic unit that a drive can normally physically read and write.
It doesn't read or write half a sector.
When emulating a write to a 512 byte logical block with 4096 byte physical blocks on the media, it has to read the whole 4K sector, modify it with the changed 512 bytes, and rewrite the entire 4K sector.The concept of sectors could be hidden from the interface, theoretically.
You could put the whole file system into the drive (OSD), for example, or allow the host to address bytes, hiding all the read/modify/writes.
But, all the common hard drive interfaces (ATA/SCSI) use blocks/sectors.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30581462</id>
	<title>/. at its best!</title>
	<author>AP31R0N</author>
	<datestamp>1262098080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The replies to my question here exemplify<nobr> <wbr></nobr>/. at its best.  Informative answers with no snark.  Thanks to everyone who replied.  i learned quite a bit.</p></htmltext>
<tokenext>The replies to my question here exemplify / .
at its best .
Informative answers with no snark .
Thanks to everyone who replied .
i learned quite a bit .</tokentext>
<sentencetext>The replies to my question here exemplify /.
at its best.
Informative answers with no snark.
Thanks to everyone who replied.
i learned quite a bit.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572496</id>
	<title>Re:Why are there sectors?</title>
	<author>donscarletti</author>
	<datestamp>1262022840000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>A sector used to be quite literally a sector of a disc in the mathematical sense, like a wedge shape that spins around. Now with LBA (labeling hard drive's blocks in series from zero rather than by their physical position) it is just like a block on your filesystem, but on the hardware instead, it is a blob of data that must be read or written as a whole. The rationale is that you are not likely to ever want to read or write one byte at a time, so there is no reason to make the hard disk handle requests for one byte. The difference between a "sector" and a block is that a block on a file system should not be smaller than a sector on the hard drive since an OS can pretend two, four, etc. sectors is a single block, it cannot cut a sector in half.</p><p>The upshot of this, is unlike memory which is addressable to the byte, hard discs can be much bigger compared to the address range since it only needs volume/blocksize addresses to locate the data, so even with a block size of 512, a 2 Terabyte (base2) volume may be sufficiently covered with a 32 bit address space, this makes everything a lot easier and more efficient.</p><p>Anyway, in answer to your question, sectors are still as useful as they ever were, just they might not actually be sectors anymore because of LBA. Maybe they are, I'm not sure, I've only written hard disc drivers, I've never built one of the things.</p></htmltext>
<tokenext>A sector used to be quite literally a sector of a disc in the mathematical sense , like a wedge shape that spins around .
Now with LBA ( labeling hard drive 's blocks in series from zero rather than by their physical position ) it is just like a block on your filesystem , but on the hardware instead , it is a blob of data that must be read or written as a whole .
The rationale is that you are not likely to ever want to read or write one byte at a time , so there is no reason to make the hard disk handle requests for one byte .
The difference between a " sector " and a block is that a block on a file system should not be smaller than a sector on the hard drive since an OS can pretend two , four , etc .
sectors is a single block , it can not cut a sector in half.The upshot of this , is unlike memory which is addressable to the byte , hard discs can be much bigger compared to the address range since it only needs volume/blocksize addresses to locate the data , so even with a block size of 512 , a 2 Terabyte ( base2 ) volume may be sufficiently covered with a 32 bit address space , this makes everything a lot easier and more efficient.Anyway , in answer to your question , sectors are still as useful as they ever were , just they might not actually be sectors anymore because of LBA .
Maybe they are , I 'm not sure , I 've only written hard disc drivers , I 've never built one of the things .</tokentext>
<sentencetext>A sector used to be quite literally a sector of a disc in the mathematical sense, like a wedge shape that spins around.
Now with LBA (labeling hard drive's blocks in series from zero rather than by their physical position) it is just like a block on your filesystem, but on the hardware instead, it is a blob of data that must be read or written as a whole.
The rationale is that you are not likely to ever want to read or write one byte at a time, so there is no reason to make the hard disk handle requests for one byte.
The difference between a "sector" and a block is that a block on a file system should not be smaller than a sector on the hard drive since an OS can pretend two, four, etc.
sectors is a single block, it cannot cut a sector in half.The upshot of this, is unlike memory which is addressable to the byte, hard discs can be much bigger compared to the address range since it only needs volume/blocksize addresses to locate the data, so even with a block size of 512, a 2 Terabyte (base2) volume may be sufficiently covered with a 32 bit address space, this makes everything a lot easier and more efficient.Anyway, in answer to your question, sectors are still as useful as they ever were, just they might not actually be sectors anymore because of LBA.
Maybe they are, I'm not sure, I've only written hard disc drivers, I've never built one of the things.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573470</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262026980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>*ahem*, I'm sorry to tell you that byte actually stands for "binary octet"</p></htmltext>
<tokenext>* ahem * , I 'm sorry to tell you that byte actually stands for " binary octet "</tokentext>
<sentencetext>*ahem*, I'm sorry to tell you that byte actually stands for "binary octet"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578568</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262015040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Actually, a ``bite'' is defined to be 10 bits and the corresponding nibble is 5 bits.  People generally prefer byte and nybble as they are powers of 2 rather than lacking any power at all.</p></htmltext>
<tokenext>Actually , a ` ` bite' ' is defined to be 10 bits and the corresponding nibble is 5 bits .
People generally prefer byte and nybble as they are powers of 2 rather than lacking any power at all .</tokentext>
<sentencetext>Actually, a ``bite'' is defined to be 10 bits and the corresponding nibble is 5 bits.
People generally prefer byte and nybble as they are powers of 2 rather than lacking any power at all.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572430</id>
	<title>Re:disable ECC?</title>
	<author>butlerm</author>
	<datestamp>1262022480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>That's insane.  ECC at the hardware / firmware level corrects the vast majority of bit errors transparently in a manner that is invisible to the operating system. If you took out sector level ECC, the drives would be useless in anything other than a ZFS RAID configuration, and even then performance would drop in the presence of trivially ECC correctable errors, due to the re-reads and stripe reconstructions at the filesystem level.</p><p>Drive performance would probably drop because the heads would have to stay in closer alignment without the ability of ECC to correct data read errors caused by small vibrations and electrical noise.  In addition, sector relocations would probably increase because tiny flaws that do not impair the ability of a drive to write an ECC correctable sector would force the drive to remap that sector to another part of the disk.</p><p>It is a similar issue with various wire level data transmission schemes.  If DSL connections did not use error correcting codes, they would suffer much higher packet loss rates than they do now, especially at distance.  Most those packets would generally get retransmitted due to transport level checksum errors, but why resort to performance impairing fall back measures when the problem can be largely eliminated at a lower level?</p></htmltext>
<tokenext>That 's insane .
ECC at the hardware / firmware level corrects the vast majority of bit errors transparently in a manner that is invisible to the operating system .
If you took out sector level ECC , the drives would be useless in anything other than a ZFS RAID configuration , and even then performance would drop in the presence of trivially ECC correctable errors , due to the re-reads and stripe reconstructions at the filesystem level.Drive performance would probably drop because the heads would have to stay in closer alignment without the ability of ECC to correct data read errors caused by small vibrations and electrical noise .
In addition , sector relocations would probably increase because tiny flaws that do not impair the ability of a drive to write an ECC correctable sector would force the drive to remap that sector to another part of the disk.It is a similar issue with various wire level data transmission schemes .
If DSL connections did not use error correcting codes , they would suffer much higher packet loss rates than they do now , especially at distance .
Most those packets would generally get retransmitted due to transport level checksum errors , but why resort to performance impairing fall back measures when the problem can be largely eliminated at a lower level ?</tokentext>
<sentencetext>That's insane.
ECC at the hardware / firmware level corrects the vast majority of bit errors transparently in a manner that is invisible to the operating system.
If you took out sector level ECC, the drives would be useless in anything other than a ZFS RAID configuration, and even then performance would drop in the presence of trivially ECC correctable errors, due to the re-reads and stripe reconstructions at the filesystem level.Drive performance would probably drop because the heads would have to stay in closer alignment without the ability of ECC to correct data read errors caused by small vibrations and electrical noise.
In addition, sector relocations would probably increase because tiny flaws that do not impair the ability of a drive to write an ECC correctable sector would force the drive to remap that sector to another part of the disk.It is a similar issue with various wire level data transmission schemes.
If DSL connections did not use error correcting codes, they would suffer much higher packet loss rates than they do now, especially at distance.
Most those packets would generally get retransmitted due to transport level checksum errors, but why resort to performance impairing fall back measures when the problem can be largely eliminated at a lower level?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30579046</id>
	<title>Re:Factors of 10</title>
	<author>toddestan</author>
	<datestamp>1262020500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>It's also worth noting that this is Microsoft's fault. Other OS's are doing it properly. Microsoft only does it properly when it benefits them.</p></div> </blockquote><p>Back in the old days, what MS-DOS and the harddrive manufacturers claimed matched up fine.  It was the harddrive manufacturers who decided to buck convention and redefine what a megabyte so they could advertise their drives as bigger than they really were.  Microsoft is just doing what they've been doing for the past 25+ years.</p><p>Besides, other OS's still use the binary definitions of kilo- and mega- when it suits them.  Compare the results of free -k and free -m on Linux, for example.</p></div>
	</htmltext>
<tokenext>It 's also worth noting that this is Microsoft 's fault .
Other OS 's are doing it properly .
Microsoft only does it properly when it benefits them .
Back in the old days , what MS-DOS and the harddrive manufacturers claimed matched up fine .
It was the harddrive manufacturers who decided to buck convention and redefine what a megabyte so they could advertise their drives as bigger than they really were .
Microsoft is just doing what they 've been doing for the past 25 + years.Besides , other OS 's still use the binary definitions of kilo- and mega- when it suits them .
Compare the results of free -k and free -m on Linux , for example .</tokentext>
<sentencetext>It's also worth noting that this is Microsoft's fault.
Other OS's are doing it properly.
Microsoft only does it properly when it benefits them.
Back in the old days, what MS-DOS and the harddrive manufacturers claimed matched up fine.
It was the harddrive manufacturers who decided to buck convention and redefine what a megabyte so they could advertise their drives as bigger than they really were.
Microsoft is just doing what they've been doing for the past 25+ years.Besides, other OS's still use the binary definitions of kilo- and mega- when it suits them.
Compare the results of free -k and free -m on Linux, for example.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577616</id>
	<title>Re:Isn't this just a firmware change?</title>
	<author>Anonymous</author>
	<datestamp>1262007780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It is not, at least for this case. The article clearly states that while the partitioning will be done at the firmware level, the firwmare capability itself will NOT be rolled back, as it largely depends on the platters themselves.</p></htmltext>
<tokenext>It is not , at least for this case .
The article clearly states that while the partitioning will be done at the firmware level , the firwmare capability itself will NOT be rolled back , as it largely depends on the platters themselves .</tokentext>
<sentencetext>It is not, at least for this case.
The article clearly states that while the partitioning will be done at the firmware level, the firwmare capability itself will NOT be rolled back, as it largely depends on the platters themselves.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577410</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262005920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>A byte can be 10 bits; it's an architecture-specific quantity.  An octet is always 8 bits.</p></div><p>isnt it: a word can be 10 bits, an byte is always an octet = 8 bits.</p><p>Ive seen different word lengths but not never different byte lengths. Maybe I havent seen enough..</p></div>
	</htmltext>
<tokenext>A byte can be 10 bits ; it 's an architecture-specific quantity .
An octet is always 8 bits.isnt it : a word can be 10 bits , an byte is always an octet = 8 bits.Ive seen different word lengths but not never different byte lengths .
Maybe I havent seen enough. .</tokentext>
<sentencetext>A byte can be 10 bits; it's an architecture-specific quantity.
An octet is always 8 bits.isnt it: a word can be 10 bits, an byte is always an octet = 8 bits.Ive seen different word lengths but not never different byte lengths.
Maybe I havent seen enough..
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576574</id>
	<title>Re:disable ECC?</title>
	<author>dfghjk</author>
	<datestamp>1261999680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Sounds terrible.  I don't want mandatory RAID to correct for errors that occur frequently, I don't want to burden the main system with work that has always been done effectively within hardware, and I want my error handling performed close to the metal.  It isn't as though space is at premium these days.</p><p>The fundamental design of RAID assumes that drives are capable of knowing when they fail and that capability relies on embedded ECC.  ZFS seems to think doing a poor imitation of that on the host CPU is a great idea but I don't.</p></htmltext>
<tokenext>Sounds terrible .
I do n't want mandatory RAID to correct for errors that occur frequently , I do n't want to burden the main system with work that has always been done effectively within hardware , and I want my error handling performed close to the metal .
It is n't as though space is at premium these days.The fundamental design of RAID assumes that drives are capable of knowing when they fail and that capability relies on embedded ECC .
ZFS seems to think doing a poor imitation of that on the host CPU is a great idea but I do n't .</tokentext>
<sentencetext>Sounds terrible.
I don't want mandatory RAID to correct for errors that occur frequently, I don't want to burden the main system with work that has always been done effectively within hardware, and I want my error handling performed close to the metal.
It isn't as though space is at premium these days.The fundamental design of RAID assumes that drives are capable of knowing when they fail and that capability relies on embedded ECC.
ZFS seems to think doing a poor imitation of that on the host CPU is a great idea but I don't.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577272</id>
	<title>Virtual Machine (vmware, virtual box, etc)</title>
	<author>Anonymous</author>
	<datestamp>1262004720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What impact will this have on Virtual Machines with respect to their Guest OS?</p></htmltext>
<tokenext>What impact will this have on Virtual Machines with respect to their Guest OS ?</tokentext>
<sentencetext>What impact will this have on Virtual Machines with respect to their Guest OS?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572326</id>
	<title>Re:Why are there sectors?</title>
	<author>Anonymous</author>
	<datestamp>1262022120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sectors allow the address space of the drive to be smaller by grouping bytes.  This reduces the amount of space on the drive needed for keeping track of where the files are located.  The downside, of course, is that in general, no more than one file can occupy a given sector (though a file usually occupies multiple sectors).  Although it could be done to eliminate sectors by using a run-length addressing system within the filesystem, this would quickly break down if aggressive defragmentation was not performed on a highly active drive (though a filesystem could abstract sectoring on it's own, and virtual filesystems, such as ISO files do)</p></htmltext>
<tokenext>Sectors allow the address space of the drive to be smaller by grouping bytes .
This reduces the amount of space on the drive needed for keeping track of where the files are located .
The downside , of course , is that in general , no more than one file can occupy a given sector ( though a file usually occupies multiple sectors ) .
Although it could be done to eliminate sectors by using a run-length addressing system within the filesystem , this would quickly break down if aggressive defragmentation was not performed on a highly active drive ( though a filesystem could abstract sectoring on it 's own , and virtual filesystems , such as ISO files do )</tokentext>
<sentencetext>Sectors allow the address space of the drive to be smaller by grouping bytes.
This reduces the amount of space on the drive needed for keeping track of where the files are located.
The downside, of course, is that in general, no more than one file can occupy a given sector (though a file usually occupies multiple sectors).
Although it could be done to eliminate sectors by using a run-length addressing system within the filesystem, this would quickly break down if aggressive defragmentation was not performed on a highly active drive (though a filesystem could abstract sectoring on it's own, and virtual filesystems, such as ISO files do)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572998</id>
	<title>Re:Factors of 10</title>
	<author>wastedlife</author>
	<datestamp>1262024820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I know that when rating SATA bandwidth, it uses 10 bits per byte, but I thought that was due to it using 8b/10b encoding.</p></htmltext>
<tokenext>I know that when rating SATA bandwidth , it uses 10 bits per byte , but I thought that was due to it using 8b/10b encoding .</tokentext>
<sentencetext>I know that when rating SATA bandwidth, it uses 10 bits per byte, but I thought that was due to it using 8b/10b encoding.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573282</id>
	<title>Re:Isn't this just a firmware change?</title>
	<author>Anonymous</author>
	<datestamp>1262026020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>if the business depends on xp so much, the IT dept actually failed at being capable of such things...</p></htmltext>
<tokenext>if the business depends on xp so much , the IT dept actually failed at being capable of such things.. .</tokentext>
<sentencetext>if the business depends on xp so much, the IT dept actually failed at being capable of such things...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30588684</id>
	<title>Re:Factors of 10</title>
	<author>Kalriath</author>
	<datestamp>1262090760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>4096 byte sectors are fine. It's nice that we'll get roughly 10\% more usable space for no cost.</p><p>But I think it'd be nice if when I open a 4KiB file it said 4KiB. According to metric prefixes accepted in virtually every other field, 4096 bytes is 4.1KB (or 4.096KB to be exact) Being "digital" does not give the right to use the wrong prefixes and cause confusion.</p><p>It's also worth noting that this is Microsoft's fault. Other OS's are doing it properly. Microsoft only does it properly when it benefits them. HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix, so people feel cheated out of space. And the issue will only get worse... Every time we jump from one incorrect prefix to another.</p></div><p>Give it up.  Noone wants to use stupid units of measure that sound like something you feed your cat.  KB is fine.</p></div>
	</htmltext>
<tokenext>4096 byte sectors are fine .
It 's nice that we 'll get roughly 10 \ % more usable space for no cost.But I think it 'd be nice if when I open a 4KiB file it said 4KiB .
According to metric prefixes accepted in virtually every other field , 4096 bytes is 4.1KB ( or 4.096KB to be exact ) Being " digital " does not give the right to use the wrong prefixes and cause confusion.It 's also worth noting that this is Microsoft 's fault .
Other OS 's are doing it properly .
Microsoft only does it properly when it benefits them .
HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix , so people feel cheated out of space .
And the issue will only get worse... Every time we jump from one incorrect prefix to another.Give it up .
Noone wants to use stupid units of measure that sound like something you feed your cat .
KB is fine .</tokentext>
<sentencetext>4096 byte sectors are fine.
It's nice that we'll get roughly 10\% more usable space for no cost.But I think it'd be nice if when I open a 4KiB file it said 4KiB.
According to metric prefixes accepted in virtually every other field, 4096 bytes is 4.1KB (or 4.096KB to be exact) Being "digital" does not give the right to use the wrong prefixes and cause confusion.It's also worth noting that this is Microsoft's fault.
Other OS's are doing it properly.
Microsoft only does it properly when it benefits them.
HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix, so people feel cheated out of space.
And the issue will only get worse... Every time we jump from one incorrect prefix to another.Give it up.
Noone wants to use stupid units of measure that sound like something you feed your cat.
KB is fine.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572014</id>
	<title>Give me some context</title>
	<author>KnownIssues</author>
	<datestamp>1262020620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How many Libraries of Congress can you store in that?</htmltext>
<tokenext>How many Libraries of Congress can you store in that ?</tokentext>
<sentencetext>How many Libraries of Congress can you store in that?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572218</id>
	<title>Re:Care to provide examples?</title>
	<author>BobMcD</author>
	<datestamp>1262021700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's a terrible hint.  Now I have to RTFA.  THANKS!</p></htmltext>
<tokenext>That 's a terrible hint .
Now I have to RTFA .
THANKS !</tokentext>
<sentencetext>That's a terrible hint.
Now I have to RTFA.
THANKS!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573202</id>
	<title>remember HPFS, OS/2 ?</title>
	<author>Anonymous</author>
	<datestamp>1262025600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>This brings back memories of the HPFS disasters in Asia where they used 4k disks back in the day... and HPFS was set to use 512 sector sizes.....</p><p>Surprising nothing changes that much.</p></htmltext>
<tokenext>This brings back memories of the HPFS disasters in Asia where they used 4k disks back in the day... and HPFS was set to use 512 sector sizes.....Surprising nothing changes that much .</tokentext>
<sentencetext>This brings back memories of the HPFS disasters in Asia where they used 4k disks back in the day... and HPFS was set to use 512 sector sizes.....Surprising nothing changes that much.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572168</id>
	<title>Re:disable ECC?</title>
	<author>Jeff DeMaagd</author>
	<datestamp>1262021460000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>I can see this working for drives made specifically for RAIDs.  Lose ECC on single drive configurations and you're asking for trouble.  At least for RAIDS, a controller would need to be aware of this and do the remapping themselves, in the end, I don't know if it's worth doing this at all.  If some enterprising RAID controller company could prove it works better to do it this way, then I can see it happening.</p></htmltext>
<tokenext>I can see this working for drives made specifically for RAIDs .
Lose ECC on single drive configurations and you 're asking for trouble .
At least for RAIDS , a controller would need to be aware of this and do the remapping themselves , in the end , I do n't know if it 's worth doing this at all .
If some enterprising RAID controller company could prove it works better to do it this way , then I can see it happening .</tokentext>
<sentencetext>I can see this working for drives made specifically for RAIDs.
Lose ECC on single drive configurations and you're asking for trouble.
At least for RAIDS, a controller would need to be aware of this and do the remapping themselves, in the end, I don't know if it's worth doing this at all.
If some enterprising RAID controller company could prove it works better to do it this way, then I can see it happening.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572634</id>
	<title>Re:Paying for More Slack Space.</title>
	<author>butlerm</author>
	<datestamp>1262023320000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Any change in sector size that doesn't affect the filesystem block size will not affect the number of KB required to store a file at all.   Since virtually every filesystem already uses 4 KB block sizes by default a change to 4KB logical or physical sector sizes will not have an effect on storage requirements.</p></htmltext>
<tokenext>Any change in sector size that does n't affect the filesystem block size will not affect the number of KB required to store a file at all .
Since virtually every filesystem already uses 4 KB block sizes by default a change to 4KB logical or physical sector sizes will not have an effect on storage requirements .</tokentext>
<sentencetext>Any change in sector size that doesn't affect the filesystem block size will not affect the number of KB required to store a file at all.
Since virtually every filesystem already uses 4 KB block sizes by default a change to 4KB logical or physical sector sizes will not have an effect on storage requirements.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573488</id>
	<title>You don't seem to get this whole base 2 thing :-(</title>
	<author>Zero\_\_Kelvin</author>
	<datestamp>1262027040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>"If they want to use base10 the first thing they should do is respecify a byte to be 10bits."</p></div></blockquote><p>Why would you want to change a byte to three bits?<nobr> <wbr></nobr>;-)<br> <br>All joking aside, changing a "byte" to be capable of storing a number from 0 through 1023 rather than 0 through 254 doesn't help matters one bit (OK, maybe not <b> <i>all</i></b>  joking aside)</p></div>
	</htmltext>
<tokenext>" If they want to use base10 the first thing they should do is respecify a byte to be 10bits .
" Why would you want to change a byte to three bits ?
; - ) All joking aside , changing a " byte " to be capable of storing a number from 0 through 1023 rather than 0 through 254 does n't help matters one bit ( OK , maybe not all joking aside )</tokentext>
<sentencetext>"If they want to use base10 the first thing they should do is respecify a byte to be 10bits.
"Why would you want to change a byte to three bits?
;-) All joking aside, changing a "byte" to be capable of storing a number from 0 through 1023 rather than 0 through 254 doesn't help matters one bit (OK, maybe not  all  joking aside)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576714</id>
	<title>Microsofts Take Away</title>
	<author>Anonymous</author>
	<datestamp>1262000760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>But Windows is the only operating system anyone would even need. And Microsoft Money apparently is the only money HDD Manufacturers will ever need.</htmltext>
<tokenext>But Windows is the only operating system anyone would even need .
And Microsoft Money apparently is the only money HDD Manufacturers will ever need .</tokentext>
<sentencetext>But Windows is the only operating system anyone would even need.
And Microsoft Money apparently is the only money HDD Manufacturers will ever need.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577290</id>
	<title>Re:Care to provide examples?</title>
	<author>mathfeel</author>
	<datestamp>1262004780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The riddle would be funnier and clearer if it says<nobr> <wbr></nobr>...colloquial name for <em>10 days old urine<em>.</em></em></htmltext>
<tokenext>The riddle would be funnier and clearer if it says ...colloquial name for 10 days old urine .</tokentext>
<sentencetext>The riddle would be funnier and clearer if it says ...colloquial name for 10 days old urine.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572536</id>
	<title>Re:Paying for More Slack Space</title>
	<author>Volante3192</author>
	<datestamp>1262022960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Well, the trend today, especially with large drives, is to go for a cluster size of 4k anyway.  Sure, there'll be a lot of system files under 4k, but there's going to be much more music and pictures over 4k that will likely take more space.</p></htmltext>
<tokenext>Well , the trend today , especially with large drives , is to go for a cluster size of 4k anyway .
Sure , there 'll be a lot of system files under 4k , but there 's going to be much more music and pictures over 4k that will likely take more space .</tokentext>
<sentencetext>Well, the trend today, especially with large drives, is to go for a cluster size of 4k anyway.
Sure, there'll be a lot of system files under 4k, but there's going to be much more music and pictures over 4k that will likely take more space.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578294</id>
	<title>Re:Factors of 10</title>
	<author>Glonoinha</author>
	<datestamp>1262013000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It appears this discussion may devolve into a KB vs. KiB, MB vs. MiB discussion.<br>I'll check back in a while just in case.</p></htmltext>
<tokenext>It appears this discussion may devolve into a KB vs. KiB , MB vs. MiB discussion.I 'll check back in a while just in case .</tokentext>
<sentencetext>It appears this discussion may devolve into a KB vs. KiB, MB vs. MiB discussion.I'll check back in a while just in case.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573556</id>
	<title>Re:Factors of 10</title>
	<author>fbjon</author>
	<datestamp>1262027400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There is no standard that specifies that it must be any particular number of bits, however, a byte is USUALLY 8 bits. But not necessarily.</htmltext>
<tokenext>There is no standard that specifies that it must be any particular number of bits , however , a byte is USUALLY 8 bits .
But not necessarily .</tokentext>
<sentencetext>There is no standard that specifies that it must be any particular number of bits, however, a byte is USUALLY 8 bits.
But not necessarily.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573006</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572158</id>
	<title>Re:Factors of 10</title>
	<author>drainbramage</author>
	<datestamp>1262021400000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>Mine goes to 11.</p></htmltext>
<tokenext>Mine goes to 11 .</tokentext>
<sentencetext>Mine goes to 11.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662</id>
	<title>Re:Care to provide examples?</title>
	<author>Anonymous</author>
	<datestamp>1262018940000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>I realize this is Slashdot, but both of the articles linked talk about the affected operating system. Hint: It shares an ending with a colloquial name for urine.</htmltext>
<tokenext>I realize this is Slashdot , but both of the articles linked talk about the affected operating system .
Hint : It shares an ending with a colloquial name for urine .</tokentext>
<sentencetext>I realize this is Slashdot, but both of the articles linked talk about the affected operating system.
Hint: It shares an ending with a colloquial name for urine.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571532</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30575286</id>
	<title>Re:Moot Point</title>
	<author>butlerm</author>
	<datestamp>1261992780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Actually, with flash drives everything related to the issue is much *worse*, due to the way flash works - the internal block sizes are huge (128KB).  Because of this, contemporary flash drives are enormously complex, sort of like a filesystem with a 128 KB internal block size that sub allocates (and moves around, and coalesces) lots of little 512 byte "sectors" for presentation to the outside world.</p></htmltext>
<tokenext>Actually , with flash drives everything related to the issue is much * worse * , due to the way flash works - the internal block sizes are huge ( 128KB ) .
Because of this , contemporary flash drives are enormously complex , sort of like a filesystem with a 128 KB internal block size that sub allocates ( and moves around , and coalesces ) lots of little 512 byte " sectors " for presentation to the outside world .</tokentext>
<sentencetext>Actually, with flash drives everything related to the issue is much *worse*, due to the way flash works - the internal block sizes are huge (128KB).
Because of this, contemporary flash drives are enormously complex, sort of like a filesystem with a 128 KB internal block size that sub allocates (and moves around, and coalesces) lots of little 512 byte "sectors" for presentation to the outside world.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573168</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573500</id>
	<title>Er, wait: Don't 'cross the streams'</title>
	<author>WheelDweller</author>
	<datestamp>1262027100000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>So we turn off the hardware-generated CRCs made by the hardware guys, locked into PROMs somewhere, so the OS can do it?</p><p>Can we think this through a little farther?</p><p>There's a reason for the value of firmware doing it's job, and an OS doing it's job. The division of labor is important here. The OS, while better these days, is more likely to have tables thrown into RAM, accessible by other programs...like rootkits, viruses and other circus-ware.</p><p>Microsoft tried this once; it was call "Stacker" and it convinced everyone I know to reformat their drives, as well as to lose every bit of data on them.</p><p>Yeah, I know: they had good reasons this would work well, without any problems.</p><p>Lesson here: the hardware guys work with gears. The OS guys work with clouds. I've seen hardware guys outsmart OS guys time after time, because the hardware guys can \_prove\_ what they think to be true.  This is an important factor.</p><p>Just more ramblin's from an old man who's seen this before.</p></htmltext>
<tokenext>So we turn off the hardware-generated CRCs made by the hardware guys , locked into PROMs somewhere , so the OS can do it ? Can we think this through a little farther ? There 's a reason for the value of firmware doing it 's job , and an OS doing it 's job .
The division of labor is important here .
The OS , while better these days , is more likely to have tables thrown into RAM , accessible by other programs...like rootkits , viruses and other circus-ware.Microsoft tried this once ; it was call " Stacker " and it convinced everyone I know to reformat their drives , as well as to lose every bit of data on them.Yeah , I know : they had good reasons this would work well , without any problems.Lesson here : the hardware guys work with gears .
The OS guys work with clouds .
I 've seen hardware guys outsmart OS guys time after time , because the hardware guys can \ _prove \ _ what they think to be true .
This is an important factor.Just more ramblin 's from an old man who 's seen this before .</tokentext>
<sentencetext>So we turn off the hardware-generated CRCs made by the hardware guys, locked into PROMs somewhere, so the OS can do it?Can we think this through a little farther?There's a reason for the value of firmware doing it's job, and an OS doing it's job.
The division of labor is important here.
The OS, while better these days, is more likely to have tables thrown into RAM, accessible by other programs...like rootkits, viruses and other circus-ware.Microsoft tried this once; it was call "Stacker" and it convinced everyone I know to reformat their drives, as well as to lose every bit of data on them.Yeah, I know: they had good reasons this would work well, without any problems.Lesson here: the hardware guys work with gears.
The OS guys work with clouds.
I've seen hardware guys outsmart OS guys time after time, because the hardware guys can \_prove\_ what they think to be true.
This is an important factor.Just more ramblin's from an old man who's seen this before.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573082</id>
	<title>Re:Factors of 10</title>
	<author>McNihil</author>
	<datestamp>1262025240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You really want to make it difficult in the world don't-ya<nobr> <wbr></nobr>;-) Just imagine the byte ordering "woodoo" that would be needed. I don't even think an insane-mad-lunatic engineer would make something like that in the first place... talk about swimming against ALL odds.</p></htmltext>
<tokenext>You really want to make it difficult in the world do n't-ya ; - ) Just imagine the byte ordering " woodoo " that would be needed .
I do n't even think an insane-mad-lunatic engineer would make something like that in the first place... talk about swimming against ALL odds .</tokentext>
<sentencetext>You really want to make it difficult in the world don't-ya ;-) Just imagine the byte ordering "woodoo" that would be needed.
I don't even think an insane-mad-lunatic engineer would make something like that in the first place... talk about swimming against ALL odds.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574414</id>
	<title>Time to Eliminate this problem</title>
	<author>FlyingGuy</author>
	<datestamp>1262031420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>With the exception of recovery utilities no OS <b>needs</b> to know anything about the disk geometry.</p><p>Drives should simply be on a port and you either read or write a stream to that port.</p><p>The only commands sent to the drive would be to read, write, create and delete.</p><p>DMA would be handled by the drive, hell there really isn't a need for a controller.</p><p>The BIOS should be the only thing that knows anything about the drives and that would be limited to booting up.</p><p>Linux uses a "filename" to access everything from a disk, so this becomes a simple matter of the "drive subsystem" sending a command to the disk drive to create a "library" called "/" and one called "/boot" etc. etc. and even this is only a file with an index.  The drives manufactures could then do all of the low level work to handle the cluster and sector stuff ( hell even on the fly if it notices that the file sizes are getting smaller or larger. it could re-adjust things to take advantage of that fact and keep the drive completely optimized at all times.) and the OS would be none the wiser simply because it does not need to be.</p></htmltext>
<tokenext>With the exception of recovery utilities no OS needs to know anything about the disk geometry.Drives should simply be on a port and you either read or write a stream to that port.The only commands sent to the drive would be to read , write , create and delete.DMA would be handled by the drive , hell there really is n't a need for a controller.The BIOS should be the only thing that knows anything about the drives and that would be limited to booting up.Linux uses a " filename " to access everything from a disk , so this becomes a simple matter of the " drive subsystem " sending a command to the disk drive to create a " library " called " / " and one called " /boot " etc .
etc. and even this is only a file with an index .
The drives manufactures could then do all of the low level work to handle the cluster and sector stuff ( hell even on the fly if it notices that the file sizes are getting smaller or larger .
it could re-adjust things to take advantage of that fact and keep the drive completely optimized at all times .
) and the OS would be none the wiser simply because it does not need to be .</tokentext>
<sentencetext>With the exception of recovery utilities no OS needs to know anything about the disk geometry.Drives should simply be on a port and you either read or write a stream to that port.The only commands sent to the drive would be to read, write, create and delete.DMA would be handled by the drive, hell there really isn't a need for a controller.The BIOS should be the only thing that knows anything about the drives and that would be limited to booting up.Linux uses a "filename" to access everything from a disk, so this becomes a simple matter of the "drive subsystem" sending a command to the disk drive to create a "library" called "/" and one called "/boot" etc.
etc. and even this is only a file with an index.
The drives manufactures could then do all of the low level work to handle the cluster and sector stuff ( hell even on the fly if it notices that the file sizes are getting smaller or larger.
it could re-adjust things to take advantage of that fact and keep the drive completely optimized at all times.
) and the OS would be none the wiser simply because it does not need to be.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577270</id>
	<title>Re:Paying for More Slack Space</title>
	<author>TheDreadedGMan</author>
	<datestamp>1262004720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Running Windows 7 64-Bit RC here... installed on a 750GB Samsung drive formatted using defaults via the installer.</p><p>Opened the C:\Windows folder, typed "size:&lt;=4096" in the search box, found 23,347 files, selected all, right-clicked properties, I get:<br>Size: 43.0 MB (45,126,095 bytes)<br>Size on disk: 91.1 MB (95,563,776 bytes)</p><p>so they are slightly more then twice as big, these "more, smaller files"... personally 45MiB of a 698,000MiB is not bad wastage...</p></htmltext>
<tokenext>Running Windows 7 64-Bit RC here... installed on a 750GB Samsung drive formatted using defaults via the installer.Opened the C : \ Windows folder , typed " size : Size : 43.0 MB ( 45,126,095 bytes ) Size on disk : 91.1 MB ( 95,563,776 bytes ) so they are slightly more then twice as big , these " more , smaller files " ... personally 45MiB of a 698,000MiB is not bad wastage.. .</tokentext>
<sentencetext>Running Windows 7 64-Bit RC here... installed on a 750GB Samsung drive formatted using defaults via the installer.Opened the C:\Windows folder, typed "size:Size: 43.0 MB (45,126,095 bytes)Size on disk: 91.1 MB (95,563,776 bytes)so they are slightly more then twice as big, these "more, smaller files"... personally 45MiB of a 698,000MiB is not bad wastage...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573168</id>
	<title>Moot Point</title>
	<author>Archangel Michael</author>
	<datestamp>1262025480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The point is going to be Moot here really shortly. The whole idea of sectoring and block sizes and such is going to go the way of the DODO in a few short years as we move from Magnetic Media to Solid State.</p><p>And the moment we go to SSD drives, the whole game changes. The idea of physical drives spaces and such disappears, and we come a lot closer to what we now see in high end Drive Array storage, where everything is abstracted away from the OS anyways.</p><p>With SSDs we'll see new ways of upgrading / managing drive spaces, such that when the time comes to put in a bigger drive, you just drop it in, and all your data moves to the new drive tranperently in the background and when the process is completed, you just remove the old SSD, and add in another new drive(wash, rinse repeat).</p><p>We'll stop using terms like "format", "defragment", "drive", and even "volume", except to express things in terms for some of us older folks, who spent the last 30-35 years with those terms ingrained in our brain.</p><p>We're already starting to see the end of Magnetic Media. I would suspect that in 4 or 5 years, magnetic drives will be mostly gone.</p></htmltext>
<tokenext>The point is going to be Moot here really shortly .
The whole idea of sectoring and block sizes and such is going to go the way of the DODO in a few short years as we move from Magnetic Media to Solid State.And the moment we go to SSD drives , the whole game changes .
The idea of physical drives spaces and such disappears , and we come a lot closer to what we now see in high end Drive Array storage , where everything is abstracted away from the OS anyways.With SSDs we 'll see new ways of upgrading / managing drive spaces , such that when the time comes to put in a bigger drive , you just drop it in , and all your data moves to the new drive tranperently in the background and when the process is completed , you just remove the old SSD , and add in another new drive ( wash , rinse repeat ) .We 'll stop using terms like " format " , " defragment " , " drive " , and even " volume " , except to express things in terms for some of us older folks , who spent the last 30-35 years with those terms ingrained in our brain.We 're already starting to see the end of Magnetic Media .
I would suspect that in 4 or 5 years , magnetic drives will be mostly gone .</tokentext>
<sentencetext>The point is going to be Moot here really shortly.
The whole idea of sectoring and block sizes and such is going to go the way of the DODO in a few short years as we move from Magnetic Media to Solid State.And the moment we go to SSD drives, the whole game changes.
The idea of physical drives spaces and such disappears, and we come a lot closer to what we now see in high end Drive Array storage, where everything is abstracted away from the OS anyways.With SSDs we'll see new ways of upgrading / managing drive spaces, such that when the time comes to put in a bigger drive, you just drop it in, and all your data moves to the new drive tranperently in the background and when the process is completed, you just remove the old SSD, and add in another new drive(wash, rinse repeat).We'll stop using terms like "format", "defragment", "drive", and even "volume", except to express things in terms for some of us older folks, who spent the last 30-35 years with those terms ingrained in our brain.We're already starting to see the end of Magnetic Media.
I would suspect that in 4 or 5 years, magnetic drives will be mostly gone.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574536</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262032080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>it's funny because 10 is 2 in binary</p></htmltext>
<tokenext>it 's funny because 10 is 2 in binary</tokentext>
<sentencetext>it's funny because 10 is 2 in binary</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262021040000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>A byte can be 10 bits; it's an architecture-specific quantity.  An octet is always 8 bits.</htmltext>
<tokenext>A byte can be 10 bits ; it 's an architecture-specific quantity .
An octet is always 8 bits .</tokentext>
<sentencetext>A byte can be 10 bits; it's an architecture-specific quantity.
An octet is always 8 bits.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578464</id>
	<title>also</title>
	<author>shentino</author>
	<datestamp>1262014260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not just for the sake of ECC space savings</p><p>4Ki also happens to be the page granularity for most modern processors, so you wind up having to write in units of 4Ki anyway whenever pages get dirty.</p></htmltext>
<tokenext>Not just for the sake of ECC space savings4Ki also happens to be the page granularity for most modern processors , so you wind up having to write in units of 4Ki anyway whenever pages get dirty .</tokentext>
<sentencetext>Not just for the sake of ECC space savings4Ki also happens to be the page granularity for most modern processors, so you wind up having to write in units of 4Ki anyway whenever pages get dirty.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578540</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262014740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Windows 7 free activation here, just click <a href="http://www.youtube.com/watch?v=GrflYvv1Baw" title="youtube.com" rel="nofollow">Here</a> [youtube.com] - this will permanently activate your windows 7 free and you will get all full updates. this is free so go ahead and get activated now.</p></htmltext>
<tokenext>Windows 7 free activation here , just click Here [ youtube.com ] - this will permanently activate your windows 7 free and you will get all full updates .
this is free so go ahead and get activated now .</tokentext>
<sentencetext>Windows 7 free activation here, just click Here [youtube.com] - this will permanently activate your windows 7 free and you will get all full updates.
this is free so go ahead and get activated now.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578086</id>
	<title>Re:Factors of 10</title>
	<author>drsmithy</author>
	<datestamp>1262011320000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p> <i>It's also worth noting that this is Microsoft's fault. Other OS's are doing it properly. Microsoft only does it properly when it benefits them. HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix, so people feel cheated out of space.</i>
</p><p>I hate to rain on your anti-Microsoft parade, but back when hard disk manufactures realised they could make their hard disks look bigger than they really were, capacities were still being measured in 10s of MB, and *all* OSes were using power-of-two prefixes.
</p><p>The rest of your rant is about as accurate.</p></htmltext>
<tokenext>It 's also worth noting that this is Microsoft 's fault .
Other OS 's are doing it properly .
Microsoft only does it properly when it benefits them .
HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix , so people feel cheated out of space .
I hate to rain on your anti-Microsoft parade , but back when hard disk manufactures realised they could make their hard disks look bigger than they really were , capacities were still being measured in 10s of MB , and * all * OSes were using power-of-two prefixes .
The rest of your rant is about as accurate .</tokentext>
<sentencetext> It's also worth noting that this is Microsoft's fault.
Other OS's are doing it properly.
Microsoft only does it properly when it benefits them.
HDD manufacturers have faced numerous lawsuits simply because Microsoft is using the wrong prefix, so people feel cheated out of space.
I hate to rain on your anti-Microsoft parade, but back when hard disk manufactures realised they could make their hard disks look bigger than they really were, capacities were still being measured in 10s of MB, and *all* OSes were using power-of-two prefixes.
The rest of your rant is about as accurate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30579234</id>
	<title>Re:Isn't this just a firmware change?</title>
	<author>Rennt</author>
	<datestamp>1262022480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If your business applications aren't platform agnostic by 2010 your IT dept have not been doing their job.</htmltext>
<tokenext>If your business applications are n't platform agnostic by 2010 your IT dept have not been doing their job .</tokentext>
<sentencetext>If your business applications aren't platform agnostic by 2010 your IT dept have not been doing their job.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572864</id>
	<title>Re:Isn't this just a firmware change?</title>
	<author>Anonymous</author>
	<datestamp>1262024160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You just repeated what TFA states.</p></htmltext>
<tokenext>You just repeated what TFA states .</tokentext>
<sentencetext>You just repeated what TFA states.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456</id>
	<title>Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262017800000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>Why not just move it to 1000 byte sectors, then we could minimize the space lost to advertising.</p><p>(Note to accuracy nazis, this is meant to be funny)</p></htmltext>
<tokenext>Why not just move it to 1000 byte sectors , then we could minimize the space lost to advertising .
( Note to accuracy nazis , this is meant to be funny )</tokentext>
<sentencetext>Why not just move it to 1000 byte sectors, then we could minimize the space lost to advertising.
(Note to accuracy nazis, this is meant to be funny)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30575466</id>
	<title>Doesn't Affect Virtualization</title>
	<author>Xeleema</author>
	<datestamp>1261993800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So, I'm seeing all of this hubris about "Windows XP going down because 4k disks are upon us!!!"  which really makes me want to point out two things;</p><p> <b>1)</b> If you're using Virtualization with file-based storage (as opposed to disk-based storage), you're in the clear.</p><p>So we can all run a VM of WinXP for Development/Compatibility purposes if we *really* want to.  The folks requiring 3D-acceleration will take a bit of a hit, but hey, if you haven't beaten that game after 10 years, cheat and get it over with already.</p><p> <b>2)</b> Are we seriously debating the *merits* of Windows XP?</p><p>The only reason it's any good is because of 9 years of patches and bugfixes. Re-Read that last part; <i>It took them NINE years to get it going good</i>.</p></htmltext>
<tokenext>So , I 'm seeing all of this hubris about " Windows XP going down because 4k disks are upon us ! ! !
" which really makes me want to point out two things ; 1 ) If you 're using Virtualization with file-based storage ( as opposed to disk-based storage ) , you 're in the clear.So we can all run a VM of WinXP for Development/Compatibility purposes if we * really * want to .
The folks requiring 3D-acceleration will take a bit of a hit , but hey , if you have n't beaten that game after 10 years , cheat and get it over with already .
2 ) Are we seriously debating the * merits * of Windows XP ? The only reason it 's any good is because of 9 years of patches and bugfixes .
Re-Read that last part ; It took them NINE years to get it going good .</tokentext>
<sentencetext>So, I'm seeing all of this hubris about "Windows XP going down because 4k disks are upon us!!!
"  which really makes me want to point out two things; 1) If you're using Virtualization with file-based storage (as opposed to disk-based storage), you're in the clear.So we can all run a VM of WinXP for Development/Compatibility purposes if we *really* want to.
The folks requiring 3D-acceleration will take a bit of a hit, but hey, if you haven't beaten that game after 10 years, cheat and get it over with already.
2) Are we seriously debating the *merits* of Windows XP?The only reason it's any good is because of 9 years of patches and bugfixes.
Re-Read that last part; It took them NINE years to get it going good.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571966</id>
	<title>Re:intelligent interfaces</title>
	<author>petermgreen</author>
	<datestamp>1262020380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It doesn't, and indeed these WD drives will still have 512 byte logical sectors so there will be 8 logical sectors to one physical sectors.</p><p>The problem is if the partition is misaligned the OS is likely to make a load of unaligned writes. Those unaligned writes will force the drive to do a read-modify-write (which afaict will mean waiting for a complete rotation in the middle of the operation)</p><p>Add this to the fact that some systems (most notablly XP) have a habbit of aligning partitions on the boundries of cylinders* and that a typical cylinder is 63 sectors and you have a pretty much guaranteed misalignment.</p><p>It's easilly fixed if you know about it and have the right tools (WD supply one) but if you aren't aware of it you will likely get poor performance for no obvious reason.</p><p>*cylinders don't really exist on modern drives but bioses emulate them since the traditional real mode hard drive access mechanisms use them.</p></htmltext>
<tokenext>It does n't , and indeed these WD drives will still have 512 byte logical sectors so there will be 8 logical sectors to one physical sectors.The problem is if the partition is misaligned the OS is likely to make a load of unaligned writes .
Those unaligned writes will force the drive to do a read-modify-write ( which afaict will mean waiting for a complete rotation in the middle of the operation ) Add this to the fact that some systems ( most notablly XP ) have a habbit of aligning partitions on the boundries of cylinders * and that a typical cylinder is 63 sectors and you have a pretty much guaranteed misalignment.It 's easilly fixed if you know about it and have the right tools ( WD supply one ) but if you are n't aware of it you will likely get poor performance for no obvious reason .
* cylinders do n't really exist on modern drives but bioses emulate them since the traditional real mode hard drive access mechanisms use them .</tokentext>
<sentencetext>It doesn't, and indeed these WD drives will still have 512 byte logical sectors so there will be 8 logical sectors to one physical sectors.The problem is if the partition is misaligned the OS is likely to make a load of unaligned writes.
Those unaligned writes will force the drive to do a read-modify-write (which afaict will mean waiting for a complete rotation in the middle of the operation)Add this to the fact that some systems (most notablly XP) have a habbit of aligning partitions on the boundries of cylinders* and that a typical cylinder is 63 sectors and you have a pretty much guaranteed misalignment.It's easilly fixed if you know about it and have the right tools (WD supply one) but if you aren't aware of it you will likely get poor performance for no obvious reason.
*cylinders don't really exist on modern drives but bioses emulate them since the traditional real mode hard drive access mechanisms use them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571580</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574720</id>
	<title>Linux is F'd</title>
	<author>Anonymous</author>
	<datestamp>1262033040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>All of the current Linux installers still use the legacy "CHS" to partition disks (as does gparted).  It can be ignored if done manually with parted or sfdisk.</p><p>The 255*63 alignment may mis-align (depending on the disk) the data sectors of EXT* and XFS with regard to the disk blocks, forcing the disk to read-modify-write the data into the on-disk 4K sectors.  This destroys performance.</p><p>In the ATA disk information, there is data to tell the user how big the physical disk blocks are, and what the alignment of logical blocks is within the physical blocks.  Installers can then set up the partitions to minimize mis-alignment.  In either case, the "cylinders" values are meaningless except to very old BIOS, which can still work OK, as long as the MBR table is correctly set up.</p><p>One further complication is that not all disk manufacturers are going to follow the ATA spec'.  They will report disks with 4096 physical sectors as having 512-byte physical sectors, so there is no way to align them using the ATA information.  The safest course of action, then, is that for disks reporting 512-byte physical sectors, align the partitions to some multiple-of-4K boundary, like 1 Mbyte (which also leaves room for a GPT).  This will not guarantee that the partitions are aligned with the disk blocks, however.</p><p>Maybe some reviewers can start checking performance with various partition alignments and let us know which disk drives aren't following the spec'.</p></htmltext>
<tokenext>All of the current Linux installers still use the legacy " CHS " to partition disks ( as does gparted ) .
It can be ignored if done manually with parted or sfdisk.The 255 * 63 alignment may mis-align ( depending on the disk ) the data sectors of EXT * and XFS with regard to the disk blocks , forcing the disk to read-modify-write the data into the on-disk 4K sectors .
This destroys performance.In the ATA disk information , there is data to tell the user how big the physical disk blocks are , and what the alignment of logical blocks is within the physical blocks .
Installers can then set up the partitions to minimize mis-alignment .
In either case , the " cylinders " values are meaningless except to very old BIOS , which can still work OK , as long as the MBR table is correctly set up.One further complication is that not all disk manufacturers are going to follow the ATA spec' .
They will report disks with 4096 physical sectors as having 512-byte physical sectors , so there is no way to align them using the ATA information .
The safest course of action , then , is that for disks reporting 512-byte physical sectors , align the partitions to some multiple-of-4K boundary , like 1 Mbyte ( which also leaves room for a GPT ) .
This will not guarantee that the partitions are aligned with the disk blocks , however.Maybe some reviewers can start checking performance with various partition alignments and let us know which disk drives are n't following the spec' .</tokentext>
<sentencetext>All of the current Linux installers still use the legacy "CHS" to partition disks (as does gparted).
It can be ignored if done manually with parted or sfdisk.The 255*63 alignment may mis-align (depending on the disk) the data sectors of EXT* and XFS with regard to the disk blocks, forcing the disk to read-modify-write the data into the on-disk 4K sectors.
This destroys performance.In the ATA disk information, there is data to tell the user how big the physical disk blocks are, and what the alignment of logical blocks is within the physical blocks.
Installers can then set up the partitions to minimize mis-alignment.
In either case, the "cylinders" values are meaningless except to very old BIOS, which can still work OK, as long as the MBR table is correctly set up.One further complication is that not all disk manufacturers are going to follow the ATA spec'.
They will report disks with 4096 physical sectors as having 512-byte physical sectors, so there is no way to align them using the ATA information.
The safest course of action, then, is that for disks reporting 512-byte physical sectors, align the partitions to some multiple-of-4K boundary, like 1 Mbyte (which also leaves room for a GPT).
This will not guarantee that the partitions are aligned with the disk blocks, however.Maybe some reviewers can start checking performance with various partition alignments and let us know which disk drives aren't following the spec'.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572412</id>
	<title>Re:disable ECC?</title>
	<author>TheLink</author>
	<datestamp>1262022420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>If they really did that, I'd say they were clueless. Such a feature would increase the odds of error.<br><br>ZFS might checksum every block. But what happens when ZFS is not everywhere? Does the BIOS or whatever equivalent support ZFS checksumming for reading the boot sectors? So those sectors better be 100\% or you better be turning it off for boot drives. You have to use ZFS everywhere and for everything. For example, if you ever try to image a 1TB disk without ECC, the odds of bit errors will be high. Even if ZFS can repair it - you'd only find out much later (too late?) and likely after another error prone write.<br><br>Such a feature would just be creating more opportunities for people to get things wrong.<br><br>And for what benefit?<br><br>&gt; The motivating idea was that this would reduce the overhead involved on ECC and gain extra space.<br><br>I think the people who'd want ZFS or RAID would rather have better reliability than the 10\% or so extra space.<br><br>Even if they don't know it at first<nobr> <wbr></nobr>;).</htmltext>
<tokenext>If they really did that , I 'd say they were clueless .
Such a feature would increase the odds of error.ZFS might checksum every block .
But what happens when ZFS is not everywhere ?
Does the BIOS or whatever equivalent support ZFS checksumming for reading the boot sectors ?
So those sectors better be 100 \ % or you better be turning it off for boot drives .
You have to use ZFS everywhere and for everything .
For example , if you ever try to image a 1TB disk without ECC , the odds of bit errors will be high .
Even if ZFS can repair it - you 'd only find out much later ( too late ?
) and likely after another error prone write.Such a feature would just be creating more opportunities for people to get things wrong.And for what benefit ? &gt; The motivating idea was that this would reduce the overhead involved on ECC and gain extra space.I think the people who 'd want ZFS or RAID would rather have better reliability than the 10 \ % or so extra space.Even if they do n't know it at first ; ) .</tokentext>
<sentencetext>If they really did that, I'd say they were clueless.
Such a feature would increase the odds of error.ZFS might checksum every block.
But what happens when ZFS is not everywhere?
Does the BIOS or whatever equivalent support ZFS checksumming for reading the boot sectors?
So those sectors better be 100\% or you better be turning it off for boot drives.
You have to use ZFS everywhere and for everything.
For example, if you ever try to image a 1TB disk without ECC, the odds of bit errors will be high.
Even if ZFS can repair it - you'd only find out much later (too late?
) and likely after another error prone write.Such a feature would just be creating more opportunities for people to get things wrong.And for what benefit?&gt; The motivating idea was that this would reduce the overhead involved on ECC and gain extra space.I think the people who'd want ZFS or RAID would rather have better reliability than the 10\% or so extra space.Even if they don't know it at first ;).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573070</id>
	<title>Re-Format old drives?</title>
	<author>Mojo66</author>
	<datestamp>1262025180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Are there tools to low-level format 512-byte drives into 4096-byte ones? I gather this would increse capacity by 13\%.</htmltext>
<tokenext>Are there tools to low-level format 512-byte drives into 4096-byte ones ?
I gather this would increse capacity by 13 \ % .</tokentext>
<sentencetext>Are there tools to low-level format 512-byte drives into 4096-byte ones?
I gather this would increse capacity by 13\%.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577008</id>
	<title>The move to 4k benefits SSDs as well.</title>
	<author>Platinumrat</author>
	<datestamp>1262002860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you read anand's articles on SSDs this jump to 4k block sizes would naturally fit in with how SSDs keep track of used pages.  Thus would boost performance in the long run, if this was adopted as the new block size.</htmltext>
<tokenext>If you read anand 's articles on SSDs this jump to 4k block sizes would naturally fit in with how SSDs keep track of used pages .
Thus would boost performance in the long run , if this was adopted as the new block size .</tokentext>
<sentencetext>If you read anand's articles on SSDs this jump to 4k block sizes would naturally fit in with how SSDs keep track of used pages.
Thus would boost performance in the long run, if this was adopted as the new block size.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572700</id>
	<title>Re:disable ECC?</title>
	<author>drinkypoo</author>
	<datestamp>1262023560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>If you were going to eliminate ECC in one place or another, it wouldn't be on the drive. The drives have to operate in the real world of analog states, while the filesystem works in the virtual world of "whatever the disk actually feeds me". Disks have to have correctable ECC just to reliably give you accurate data from magnetic media at these densities. It would make more sense to upgrade the on-disk ECC and give the filesystem better access to the disk's ECC.</p></htmltext>
<tokenext>If you were going to eliminate ECC in one place or another , it would n't be on the drive .
The drives have to operate in the real world of analog states , while the filesystem works in the virtual world of " whatever the disk actually feeds me " .
Disks have to have correctable ECC just to reliably give you accurate data from magnetic media at these densities .
It would make more sense to upgrade the on-disk ECC and give the filesystem better access to the disk 's ECC .</tokentext>
<sentencetext>If you were going to eliminate ECC in one place or another, it wouldn't be on the drive.
The drives have to operate in the real world of analog states, while the filesystem works in the virtual world of "whatever the disk actually feeds me".
Disks have to have correctable ECC just to reliably give you accurate data from magnetic media at these densities.
It would make more sense to upgrade the on-disk ECC and give the filesystem better access to the disk's ECC.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572542</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262023020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Historically, yes, but nowadays "byte" is always used to refer to an octet in a system with an 8-bit, 16-bit, 32-bit, or 64-bit word (and so likely all the other 2^(3+n)-bit word systems to come down the pipe in the future).</p></htmltext>
<tokenext>Historically , yes , but nowadays " byte " is always used to refer to an octet in a system with an 8-bit , 16-bit , 32-bit , or 64-bit word ( and so likely all the other 2 ^ ( 3 + n ) -bit word systems to come down the pipe in the future ) .</tokentext>
<sentencetext>Historically, yes, but nowadays "byte" is always used to refer to an octet in a system with an 8-bit, 16-bit, 32-bit, or 64-bit word (and so likely all the other 2^(3+n)-bit word systems to come down the pipe in the future).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572588</id>
	<title>Re:disable ECC?</title>
	<author>Anonymous</author>
	<datestamp>1262023140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>One of the reasons there is so much BS and hype surrounding ZFS...</p><p>Drives already do and have for years done error correction and most revector badblocks dynamically and the OS never even knows.    It's part of how drives are so reliable as it is.   Pushing that logic up in to the filesystem just introduces more complexity to the filesystem and reduces overall reliability.</p><p>Talk to any drive engineer,  what they want the most is for filesystem engineers to stop trying to outsmart the drive guys.   THere is not a guaranteed relationship between a sector and it's location on the disk,  the drive and the firmware it has will try to figure that out the best way it can.</p><p>What they really should spend their time on is filesystems and their relationship with cache will have to change in the next decade,  solid state medias don't need caching the same way disks do,  I fully expect disks to start coming as hybrid devices with solid state storage and disk based storage as a singular device.   There are some relatively complex problems to solve to provide media awareness to all the storage algorithms.</p></htmltext>
<tokenext>One of the reasons there is so much BS and hype surrounding ZFS...Drives already do and have for years done error correction and most revector badblocks dynamically and the OS never even knows .
It 's part of how drives are so reliable as it is .
Pushing that logic up in to the filesystem just introduces more complexity to the filesystem and reduces overall reliability.Talk to any drive engineer , what they want the most is for filesystem engineers to stop trying to outsmart the drive guys .
THere is not a guaranteed relationship between a sector and it 's location on the disk , the drive and the firmware it has will try to figure that out the best way it can.What they really should spend their time on is filesystems and their relationship with cache will have to change in the next decade , solid state medias do n't need caching the same way disks do , I fully expect disks to start coming as hybrid devices with solid state storage and disk based storage as a singular device .
There are some relatively complex problems to solve to provide media awareness to all the storage algorithms .</tokentext>
<sentencetext>One of the reasons there is so much BS and hype surrounding ZFS...Drives already do and have for years done error correction and most revector badblocks dynamically and the OS never even knows.
It's part of how drives are so reliable as it is.
Pushing that logic up in to the filesystem just introduces more complexity to the filesystem and reduces overall reliability.Talk to any drive engineer,  what they want the most is for filesystem engineers to stop trying to outsmart the drive guys.
THere is not a guaranteed relationship between a sector and it's location on the disk,  the drive and the firmware it has will try to figure that out the best way it can.What they really should spend their time on is filesystems and their relationship with cache will have to change in the next decade,  solid state medias don't need caching the same way disks do,  I fully expect disks to start coming as hybrid devices with solid state storage and disk based storage as a singular device.
There are some relatively complex problems to solve to provide media awareness to all the storage algorithms.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573796</id>
	<title>Re:Factors of 10</title>
	<author>Anonymous</author>
	<datestamp>1262028420000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>Wrong.<br>A word is architecture specific.<br>A byte is ALWAYS 8 bits.</p></div><p>A byte can't possibly "always" be 8 bits, when a byte means a single character.<br>This is the definition of 'byte' from 1959.  People only started getting confused recently (Recently being the past 20 years) since the IBM 360 systems which first introduced the 8 bit byte and then became a defacto standard in the 80s.  Then as new computer users moved into the front, such as yourself, you assume a byte must be 8 bits because that is all you have seen a byte to mean.</p><p>There are systems that encode a single byte with 7, 8, 9, and 10 bits still today.</p><p>The only time a byte is 8 bits is when the system is structured around 8 bit units.<br>Hop on a PDP or Cray system and you will see a byte is 7 or 9 bits respectively.</p><p>Origins of the word 'byte':<br><a href="http://www.trailing-edge.com/~bobbemer/BYTE.HTM" title="trailing-edge.com">http://www.trailing-edge.com/~bobbemer/BYTE.HTM</a> [trailing-edge.com]</p></div>
	</htmltext>
<tokenext>Wrong.A word is architecture specific.A byte is ALWAYS 8 bits.A byte ca n't possibly " always " be 8 bits , when a byte means a single character.This is the definition of 'byte ' from 1959 .
People only started getting confused recently ( Recently being the past 20 years ) since the IBM 360 systems which first introduced the 8 bit byte and then became a defacto standard in the 80s .
Then as new computer users moved into the front , such as yourself , you assume a byte must be 8 bits because that is all you have seen a byte to mean.There are systems that encode a single byte with 7 , 8 , 9 , and 10 bits still today.The only time a byte is 8 bits is when the system is structured around 8 bit units.Hop on a PDP or Cray system and you will see a byte is 7 or 9 bits respectively.Origins of the word 'byte ' : http : //www.trailing-edge.com/ ~ bobbemer/BYTE.HTM [ trailing-edge.com ]</tokentext>
<sentencetext>Wrong.A word is architecture specific.A byte is ALWAYS 8 bits.A byte can't possibly "always" be 8 bits, when a byte means a single character.This is the definition of 'byte' from 1959.
People only started getting confused recently (Recently being the past 20 years) since the IBM 360 systems which first introduced the 8 bit byte and then became a defacto standard in the 80s.
Then as new computer users moved into the front, such as yourself, you assume a byte must be 8 bits because that is all you have seen a byte to mean.There are systems that encode a single byte with 7, 8, 9, and 10 bits still today.The only time a byte is 8 bits is when the system is structured around 8 bit units.Hop on a PDP or Cray system and you will see a byte is 7 or 9 bits respectively.Origins of the word 'byte':http://www.trailing-edge.com/~bobbemer/BYTE.HTM [trailing-edge.com]
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573006</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30582016</id>
	<title>More Space = More Porn?</title>
	<author>ttyX</author>
	<datestamp>1262102280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Whoopie!</htmltext>
<tokenext>Whoopie !</tokentext>
<sentencetext>Whoopie!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578746</id>
	<title>Re:disable ECC?</title>
	<author>rcw-home</author>
	<datestamp>1262016900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>It doesn't seem like a great idea to me. There are a lot of different ECC algorithms and implementations. It seems to me that it would be better to let the hard drive manufacturer select one that closely matches the expected signal and noise characteristics of a particular disk drive rather than some generic algorithm in the filesystem.</p></div></blockquote><p>First, I suspect that disk drive manufacturers are more keen on selecting an ECC implementation that matches their drive's <i>marketing</i> requirements.</p><p>Second, at work, I currently have a RAID1 whose backups have corrupt checksums nearly exactly half the time. As best I can tell, for whatever reason, there's a few sectors where different data got written to the two disks in the mirror. Without filesystem-level ECC, there is no guaranteed way to tell which disk has good data - if I tell the RAID controller to do a verify, I have a 50\% chance of wiping out the good data (and if I don't do a verify, LSI tech support tells me to take a hike). End-to-end checksumming is the only answer here - <a href="http://fuji.web.cern.ch/fuji/talk/2007/kelemen-2007-C5-Silent\_Corruptions.pdf" title="web.cern.ch">it's not just happening to me</a> [web.cern.ch].</p></div>
	</htmltext>
<tokenext>It does n't seem like a great idea to me .
There are a lot of different ECC algorithms and implementations .
It seems to me that it would be better to let the hard drive manufacturer select one that closely matches the expected signal and noise characteristics of a particular disk drive rather than some generic algorithm in the filesystem.First , I suspect that disk drive manufacturers are more keen on selecting an ECC implementation that matches their drive 's marketing requirements.Second , at work , I currently have a RAID1 whose backups have corrupt checksums nearly exactly half the time .
As best I can tell , for whatever reason , there 's a few sectors where different data got written to the two disks in the mirror .
Without filesystem-level ECC , there is no guaranteed way to tell which disk has good data - if I tell the RAID controller to do a verify , I have a 50 \ % chance of wiping out the good data ( and if I do n't do a verify , LSI tech support tells me to take a hike ) .
End-to-end checksumming is the only answer here - it 's not just happening to me [ web.cern.ch ] .</tokentext>
<sentencetext>It doesn't seem like a great idea to me.
There are a lot of different ECC algorithms and implementations.
It seems to me that it would be better to let the hard drive manufacturer select one that closely matches the expected signal and noise characteristics of a particular disk drive rather than some generic algorithm in the filesystem.First, I suspect that disk drive manufacturers are more keen on selecting an ECC implementation that matches their drive's marketing requirements.Second, at work, I currently have a RAID1 whose backups have corrupt checksums nearly exactly half the time.
As best I can tell, for whatever reason, there's a few sectors where different data got written to the two disks in the mirror.
Without filesystem-level ECC, there is no guaranteed way to tell which disk has good data - if I tell the RAID controller to do a verify, I have a 50\% chance of wiping out the good data (and if I don't do a verify, LSI tech support tells me to take a hike).
End-to-end checksumming is the only answer here - it's not just happening to me [web.cern.ch].
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572162</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577284
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574414
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571580
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572864
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573500
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578664
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572168
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572634
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572468
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577616
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572998
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573282
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572588
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572496
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30601540
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573470
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572478
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578568
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578294
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578828
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577410
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572158
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572674
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30579046
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577270
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574704
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30575286
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573168
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577290
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571532
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578540
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573488
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572700
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572326
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30588684
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572430
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574196
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578746
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572162
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572218
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571532
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572412
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30581462
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573556
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573006
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572244
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571532
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572536
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574536
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30579234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571708
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571580
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573796
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573006
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574098
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578772
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572226
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573978
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571532
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_28_1422253_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572014
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571776
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574196
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572326
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572496
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30581462
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571666
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30579234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577616
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572864
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572226
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573282
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572444
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30575466
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574414
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577284
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571486
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572258
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572908
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572536
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572478
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577270
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572634
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571456
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578540
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571518
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573488
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572086
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573470
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573082
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577410
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578772
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572542
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578568
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572998
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574536
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573006
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573796
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573556
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572158
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574704
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576346
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578294
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578086
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30601540
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578828
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30588684
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30579046
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573070
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571532
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571662
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30577290
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572244
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572218
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573978
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572184
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573168
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30575286
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578664
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574720
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571740
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572430
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572700
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572168
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572468
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572412
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572162
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30578746
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30573500
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30576574
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30574098
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572674
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30572588
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_28_1422253.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571580
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571966
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_28_1422253.30571708
</commentlist>
</conversation>
