the filesystem, which doesn't even know about the sector size
The filesystem certainly might know about the sector size, if it cares to have that information. On Windows, it can ask the storage stack for the sector size using an ioctl. I imagine (though I'm not certain) there would be something similar on other platforms. A filesystem doesn't necessarily "need" to know the sector size; the storage stack should always do the right thing regardless. But knowledge of the sector size can be useful for certain performance optimizations.
What problem is this actually trying to solve? Are people really finding it too difficult use their arms to drive? Or is this aimed at people who can't drive right now, because they have no arms?
The Amiga had proper co-operative multitasking around a decade(!) before Windows. Matter of fact, it was doing this before Windows 1.0 was out at all!
According to Wikipedia: Windows 1.0 was released on Nov 20, 1985. The first Amiga, the Amiga 1000, came out in 1985 (no exact date given). If Amiga preceded Windows 1.0, it was only by a matter of months.
Note that NTFS has supported EAs from the beginning. They were originally put in to support the OS/2 subsystem. Also note that NTFS EAs are logged (aka journalled), just like other file system metadata, so corruption should be rare. Contrast this with alternate data streams which, just like the primary data stream, are not logged.
keep cyberwars from escalating into full-scale combat
A noble goal. Forget trying to prevent cyberwars, but definitely contain them so that there is no actual physical combat. That way there are no real casualties, right? Somehow this instantly reminded me of the Star Trek episode "A Taste of Armageddon" (http://memory-alpha.org/en/index.php/A_Taste_of_Armageddon_%28episode%29) where two societies wage war using computer simulation, but with real human casualties. Star Trek really was ahead of its time on so many levels.
Does anyone know just how big the Groklaw archive is, anyway? Please answer in units of Libraries of Congresses, or LOCs. And how big will it be, in LOCs, after it gets added? And how big is the actual Library of Congress, in LOCs, both before and after the addition? I'd prefer it in metric LOCs (being Canadian), but I can convert from imperial LOCs if necessary. Thanks.
Oh it's implemented, in Vista (SP1 and later) / Server 2008 / Win7. It does reduce reboots, but does not eliminate them. Some reasons: 1) Not all driver updates are hotpatchable, by their nature. The Ksplice paper discusses some of these problems and omits others entirely. 2) Some of the updates distributed on Patch Tuesday are updates to third party drivers, and since third parties don't use Microsoft's hotpatching technology or some other equivalent, these often end up requiring a reboot. 3) If you're applying a batch of various driver updates (which is the usual Patch Tuesday scenario), if even ONE of those updates to not hotpatchable then you'll still have to reboot at the end. So, hotpatching is not a panacea, it's merely one technique for reducing reboots.
Reading the Ksplice paper, it's the same concept and almost identical implementation as Microsoft's hotpatching. It's pretty unbelievable that Microsoft's hotpatching was not mentioned in the paper at all, not even in the Related Work section or the References section. Hotpatching predates Ksplice by 6 years.
This may not help you if you are stuck on XP, BUT: In Vista and later, CHKDSK/B will accomplish what you want. This switch was added specifically for the scenario of transferring an image from one disk to another. I haven't had the need to actually try this myself. What it does is re-evaluate bad clusters and rebuild $BadClus based on that. However it is expensive as it needs to perform I/O on every cluster. Depending on your volume size you might have to let it run overnight or even over the weekend.:)
No, I'm not saying that "2TB should be enough for anybody", or that it's not important to support volumes > 2TB. It clearly is important, which is why we already addressed this issue by adding GPT support! What you're complaining about is that we didn't address this all the way back to XP, which did not have GPT support to begin with (in fact there was no such thing as GPT back then). If you need GPT on Windows, use a version of Windows that was released in the past 7 years. If you are stuck with XP for some reason, I outlined a way you could at least use all your space in XP, which is to use multiple 2TB volumes; another option is network-attached storage like you mention. What more do you honestly expect? Are you really claiming it is important to backport GPT support to XP? Of course if we did that, then Win2K users would complain. Backport to Win2K, then NT4 users would complain, etc. You can't just backport everything -- logically there has to be SOME point at which a particular OS version has support for something that the previous OS version didn't. That's why there are versions. Otherwise we'd all still be using DOS 1.0 or Windows 1.0 or MacOS 1.0 or...
Regarding the $20K xray machine that only works in XP: It's entirely possible it actually does work with Vista or Win7 despite the manufacturer's disclaimer. Sometimes their disclaimer is just out of date (i.e. it was made several years ago), and sometimes it's just because they haven't adequately tested it on the newer OSes and don't want to commit to anything just yet. A lot of XP and Vista drivers just work on Win7. Another option that might work is use a newer OS, but run XP in a virtual machine (either using Win7's "virtual XP mode" or some other VM solution). If a piece of hardware really doesn't work on anything newer than XP, that really means that the associated device driver or the associated user-mode software doesn't work on anything newer than XP, and whose fault is that? The manufacturer. BTW can you provide a link to the manufacturer site where they state only XP is supported? I'm interested in following up with them as to why.
Your idea of moving the mass storage to another network-accessible machine is a good one. Clearly if this will be part of a $20K+ environment, the cost of this is trivial. The fact that there are viable workarounds supports my point that supporting > 2TB local volumes on XP is not an important issue. There are far more impactful issues for MS to be working on. Like oh, improving standards support in IE!!!
Right, that is a partitioning issue. Specifically 2TB is the max partition size using MBR (master boot record), while GPT (GUID partition table) supports much larger. GPT was introduced in Vista (and has been backported to Server 2003 -- as servers are more likely to need something like this). LIke you said, nothing to do with NTFS at all. It's not that "you can make NTFS filesystems that are compatible with Vista and 7 but not with XP", it's more like "you can make filesystems that are compatible with Vista and 7 but not with XP". Note you'd have the same problem with a slightly old version of Linux too, before GPT support was added. (Look at what your Drobo page says about Linux.) Does that mean "Linux broke ext3 compatibility"? Please. Honestly, needing a > 2TB volume on XP is not a big problem anyway. It's not necessary for single drives as nobody has drives > 2TB (I'm not sure if they exist yet). So it applies mainly to drive clusters that total > 2TB. Those that have such a thing can either use a version of Windows newer than XP, or torture yourself with XP and use multiple partitions of 2TB each (which is what the Drobo does apparently). If you are using multiple partitions and want the namespaces stitched together, you might be able to use junctions.
Shadow copies are not implemented in the file system, so if there is an incompatibility there, it's not NTFS's fault. EFS on the other hand is implemented in the file system. I didn't know about the EFS incompatibility, but according to that KB, it was fixed in Vista SP1 (and by extension the fix should also be present in Win7 RTM... I'll check in to that). Thanks for the info.
The default NTFS filesystem that Win7 creates is NOT backward compatible with XP/Vista.
Total BS. The NTFS filesystem format has not changed across XP/Vista/Win7. (Incidentally the format version number is 3.1.) An NTFS 3.1 volume is completely backwards and forwards compatible across these OSes. As a developer of NTFS, I cannot let your statement slide. Please back up this claim with evidence or retract it. Incidentally in Win7 there were some changes to the default partitioning scheme but that has to do with partitioning and has nothing to do with file systems.
Knowing Microsoft, this is only useful if all your clients are Windows 7 and all your servers are Windows Server 2008. Can any early adopters confirm whether or not this is the case?
Actually the server requirement is Windows Server 2008 R2, aka "Windows 7 Server". And yes, that is the case; it's a new feature introduced in Windows 7 that other OSes have absolutely no concept of. It remains to be seen if this can be/will be backported to previous versions of Windows. My guess is probably not since it would require fairly extensive changes to the networking subsystem and impacting other subsystems as well.
True, OpenMP may be better in some cases. Apple is not aiming to optimize for every case here. Rather, they are aiming for the greatest common denominator.
ARM doesn't understand C code. A C compiler can treat char however it likes. I suspect you are talking about a particular C compiler you've encountered that happens to treat chars as unsigned by default when targetting the ARM platform. That's saying something about that particular C compiler, not the ARM platform in general.
Slashdot Mirror
the filesystem, which doesn't even know about the sector size
The filesystem certainly might know about the sector size, if it cares to have that information. On Windows, it can ask the storage stack for the sector size using an ioctl. I imagine (though I'm not certain) there would be something similar on other platforms. A filesystem doesn't necessarily "need" to know the sector size; the storage stack should always do the right thing regardless. But knowledge of the sector size can be useful for certain performance optimizations.
The secret is this: Blush. Lots and lots of blush.
There is no shortcut key to go to the URL bar
In IE, Alt-D takes you to the address bar (what you call the URL bar).
click on the search box, but again, there is no shortcut
In IE, Ctrl-E takes you to the search box.
What problem is this actually trying to solve? Are people really finding it too difficult use their arms to drive? Or is this aimed at people who can't drive right now, because they have no arms?
According to Wikipedia: Windows 1.0 was released on Nov 20, 1985. The first Amiga, the Amiga 1000, came out in 1985 (no exact date given). If Amiga preceded Windows 1.0, it was only by a matter of months.
Note that NTFS has supported EAs from the beginning. They were originally put in to support the OS/2 subsystem. Also note that NTFS EAs are logged (aka journalled), just like other file system metadata, so corruption should be rare. Contrast this with alternate data streams which, just like the primary data stream, are not logged.
A noble goal. Forget trying to prevent cyberwars, but definitely contain them so that there is no actual physical combat. That way there are no real casualties, right? Somehow this instantly reminded me of the Star Trek episode "A Taste of Armageddon" (http://memory-alpha.org/en/index.php/A_Taste_of_Armageddon_%28episode%29) where two societies wage war using computer simulation, but with real human casualties. Star Trek really was ahead of its time on so many levels.
Does anyone know just how big the Groklaw archive is, anyway? Please answer in units of Libraries of Congresses, or LOCs. And how big will it be, in LOCs, after it gets added? And how big is the actual Library of Congress, in LOCs, both before and after the addition? I'd prefer it in metric LOCs (being Canadian), but I can convert from imperial LOCs if necessary. Thanks.
Citation on those statistics?
I believe it does touch on prior art, in multiple places.
What's your proposed alternative algorithm for zeroing out a million bytes of RAM?
Oh it's implemented, in Vista (SP1 and later) / Server 2008 / Win7. It does reduce reboots, but does not eliminate them. Some reasons: 1) Not all driver updates are hotpatchable, by their nature. The Ksplice paper discusses some of these problems and omits others entirely. 2) Some of the updates distributed on Patch Tuesday are updates to third party drivers, and since third parties don't use Microsoft's hotpatching technology or some other equivalent, these often end up requiring a reboot. 3) If you're applying a batch of various driver updates (which is the usual Patch Tuesday scenario), if even ONE of those updates to not hotpatchable then you'll still have to reboot at the end. So, hotpatching is not a panacea, it's merely one technique for reducing reboots.
Reading the Ksplice paper, it's the same concept and almost identical implementation as Microsoft's hotpatching. It's pretty unbelievable that Microsoft's hotpatching was not mentioned in the paper at all, not even in the Related Work section or the References section. Hotpatching predates Ksplice by 6 years.
This may not help you if you are stuck on XP, BUT: In Vista and later, CHKDSK /B will accomplish what you want. This switch was added specifically for the scenario of transferring an image from one disk to another. I haven't had the need to actually try this myself. What it does is re-evaluate bad clusters and rebuild $BadClus based on that. However it is expensive as it needs to perform I/O on every cluster. Depending on your volume size you might have to let it run overnight or even over the weekend. :)
Regarding the $20K xray machine that only works in XP: It's entirely possible it actually does work with Vista or Win7 despite the manufacturer's disclaimer. Sometimes their disclaimer is just out of date (i.e. it was made several years ago), and sometimes it's just because they haven't adequately tested it on the newer OSes and don't want to commit to anything just yet. A lot of XP and Vista drivers just work on Win7. Another option that might work is use a newer OS, but run XP in a virtual machine (either using Win7's "virtual XP mode" or some other VM solution). If a piece of hardware really doesn't work on anything newer than XP, that really means that the associated device driver or the associated user-mode software doesn't work on anything newer than XP, and whose fault is that? The manufacturer. BTW can you provide a link to the manufacturer site where they state only XP is supported? I'm interested in following up with them as to why.
Your idea of moving the mass storage to another network-accessible machine is a good one. Clearly if this will be part of a $20K+ environment, the cost of this is trivial. The fact that there are viable workarounds supports my point that supporting > 2TB local volumes on XP is not an important issue. There are far more impactful issues for MS to be working on. Like oh, improving standards support in IE!!!
Right, that is a partitioning issue. Specifically 2TB is the max partition size using MBR (master boot record), while GPT (GUID partition table) supports much larger. GPT was introduced in Vista (and has been backported to Server 2003 -- as servers are more likely to need something like this). LIke you said, nothing to do with NTFS at all. It's not that "you can make NTFS filesystems that are compatible with Vista and 7 but not with XP", it's more like "you can make filesystems that are compatible with Vista and 7 but not with XP". Note you'd have the same problem with a slightly old version of Linux too, before GPT support was added. (Look at what your Drobo page says about Linux.) Does that mean "Linux broke ext3 compatibility"? Please. Honestly, needing a > 2TB volume on XP is not a big problem anyway. It's not necessary for single drives as nobody has drives > 2TB (I'm not sure if they exist yet). So it applies mainly to drive clusters that total > 2TB. Those that have such a thing can either use a version of Windows newer than XP, or torture yourself with XP and use multiple partitions of 2TB each (which is what the Drobo does apparently). If you are using multiple partitions and want the namespaces stitched together, you might be able to use junctions.
Shadow copies are not implemented in the file system, so if there is an incompatibility there, it's not NTFS's fault. EFS on the other hand is implemented in the file system. I didn't know about the EFS incompatibility, but according to that KB, it was fixed in Vista SP1 (and by extension the fix should also be present in Win7 RTM... I'll check in to that). Thanks for the info.
Total BS. The NTFS filesystem format has not changed across XP/Vista/Win7. (Incidentally the format version number is 3.1.) An NTFS 3.1 volume is completely backwards and forwards compatible across these OSes. As a developer of NTFS, I cannot let your statement slide. Please back up this claim with evidence or retract it. Incidentally in Win7 there were some changes to the default partitioning scheme but that has to do with partitioning and has nothing to do with file systems.
Vaginas?
Actually the server requirement is Windows Server 2008 R2, aka "Windows 7 Server". And yes, that is the case; it's a new feature introduced in Windows 7 that other OSes have absolutely no concept of. It remains to be seen if this can be/will be backported to previous versions of Windows. My guess is probably not since it would require fairly extensive changes to the networking subsystem and impacting other subsystems as well.
Now you'll have to clean out organ jams.
I think it's more likely we'll see kibicores and mebicores.
True, OpenMP may be better in some cases. Apple is not aiming to optimize for every case here. Rather, they are aiming for the greatest common denominator.
Could there be a planet somewhere that actually rains cats and dogs?
ARM doesn't understand C code. A C compiler can treat char however it likes. I suspect you are talking about a particular C compiler you've encountered that happens to treat chars as unsigned by default when targetting the ARM platform. That's saying something about that particular C compiler, not the ARM platform in general.
So much for the Neumann-Neumann dance.
Another nerd who took his sister to the prom?