If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#91
|
|||
|
|||
SSDs/HDDs, memory ...
Yousuf Khan wrote:
On 6/29/2020 4:19 PM, Carlos E.R. wrote: On 29/06/2020 21.30, Yousuf Khan wrote: On 6/29/2020 7:08 AM, Carlos E.R. wrote: Well, the attribute/permission set is different, which affects both directions. Maybe more issues? Legal? I'm sure one of the older public-domain filesystems, such as Ext3fs can be modified to include Microsoft attributes instead? I mean the source code is completely available for free. Yes, but then your own code based on it would also have to be available for free to competitors, and is not in the M$ DNA ;-p Yeah, but if it's just to add the information like the permissions and ownership information, then what kind of competitive information is left in that now? At this point in time, NTFS has been thoroughly reverse-engineered already, and most external OS's can handle NTFS as a side-gig these days, so they already know most of the attributes inside it. Besides that was the old Microsoft, this is the new Linux-friendly Microsoft. :-) Maybe they would need a team to extract the full detailed specs, and another team that never ever had a look at the code, create another code set from scratch. It seems like a total waste of time, when the source code is already available for them for free. All they'd have to do is reveal the hierarchy for their permission and ownership attributes. I don't see where there is any competitive advantage left for hiding that information anymore. Have you looked at NTFS lately ? The version string on all versions (Win7, Win8, Win10) is NTFS 3.1. And the claim is made "they're all compatible". Because they were careful to not increment the release number (blowback...). But Windows 10 has corrupted the $MFTMIRR, altered how the Volume Bitmap works (untrustworthy at runtime). This sort of stuff caused Macrium to have to issue some patched versions in the 6.x.x stream so that users could work with volumes that Windows 10 had touched. In addition, there are Reparse Points. These are metadata extensions to the filesystem. An example would be "New style compression". I don't know what the situation is on say, Windows 7, with items like this. Linux does not have Reparse points reverse engineered. Linux is not actively playing catchup. The only evidence I saw of catchup, was Fedora issuing a patch to have their Linux ignore the value in $MFTMIRR. Nobody else does that, and "dmesg" is littered with references to "can't mount your NTFS volume, **** off" message. And that's what happens when traditional $MFTMIRR value checking is done. I noticed recently, the error messages in Linux, when running into one of these New Compression items in NTFS has improved. Instead of saying "I/O error", it mentions "this OS cannot parse this information" or similar. So at least the root cause is better described. The "I/O error" thing was causing users to run WDC or Seagate disk diagnostics :-) Because of course everyone panics when they see "Abort, Retry, Fail" kinds of indicators :-) It's not really an "I/O error", because the sectors with the data that cannot be parsed, read just fine. But the software doesn't know what to do with them. To remedy a small percentage of the affected files, you can do this in an administrator command prompt window compact /compactOS:never This expands the compressed files, making more of them accessible in Linux. New compression files outside the Windows folder, you're **** outta luck. You make it sound like NTFS is "a solved problem", when Microsoft is going out of their way to make trouble. "FOSS lovers", my ass. They didn't fire all the old timers at Microsoft... Evil *******s still live in those cubicles. Now, arguments could be made, that this "improves SSD wear life", but sorry, I'm not buying it. The compression is likely part of the stretch target of installing Windows 10 on 16GB eMMC, which is a ludicrous objective. The result would be "an unusable device" or "landfill material". Perfect products for Walmart. Paul |
Ads |
#92
|
|||
|
|||
SSDs/HDDs, memory ...
Carlos E.R. wrote:
On 01/07/2020 01.10, Mayayana wrote: "Carlos E.R." wrote | The point being that in the vast majority of things | that people do, an SSD offers no advantage. You're not | going to is a difference if MS Word is saving your DOC | to disk once every 5 minutes, spending 1 ms to do it | instead of 2 ms. | | You do if you handle a 20 page document with photos or figures on every | page. Or with active links to calc sheet portions. I can hear the disk | working as I go around. | But you're not waiting for disk writes, right? Of course we are. No, you're not. Both Windows 7 and Windows 10 have a system write cache. When that cache is full, *then* you're waiting on disk writes. The cache is not full when you're saving that 3-page MSWD doc. The cache is full, when you back up a fast disk to a slow disk. ******* The other observation, is more minor. In my testing, Windows 10 has (in a recent version) implemented a small write cache per file handle. At one time, you would catch the OS writing single 4K clusters. Whereas now, it's more likely to work in units of 64K (16 clusters). It's not a change in cluster size. It's a change in behavior where a file handle doesn't have to do anything until 64K of data is ready to write. I only noticed this, when using the Passmark fragmenter. https://www.passmark.com/products/fragger/ I noticed that when run in Windows 10, it could no longer make "fine grained" fragments. The "lumps" got bigger. And I also noticed this when testing my own little C program for making fragmented test files, that its runtime characteristic had changed. I use stuff like this, for obscure performance tests. (Such as, an SSD slows down perceptibly, if the files on it are fragmented enough, so the 20 to 100usec seek time does matter.) For most reasonable levels of fragmentation (not pathological ones), you'd never notice. I'm talking about 100% fragmented disks, where the disk is just "salt n' pepper" pattern. Paul |
#93
|
|||
|
|||
SSDs/HDDs, memory ...
"Paul" wrote
| | You do if you handle a 20 page document with photos or figures on every | | page. Or with active links to calc sheet portions. I can hear the disk | | working as I go around. | | | | But you're not waiting for disk writes, right? | | Of course we are. | | No, you're not. | | Both Windows 7 and Windows 10 have a system write cache. | Even if the cache is being flushed, what kind of situation would actully make people wait for disk writes? Pretty much the only time I ever wait is complex operations on giant images. But writing those changes back to disk is in terms of ms. Maybe Carlos didn't understand. My point was that people don't actually pause their work to wait for a file update to be written to disk. If they do there's something wrong. Even in the days of 300 MHz Celeron I don't remember ever having to actually pause to wait for a file to write to disk. It writes as fast as I can click the Save menu. |
#94
|
|||
|
|||
SSDs/HDDs, memory ...
In article , Mayayana
wrote: Even if the cache is being flushed, what kind of situation would actully make people wait for disk writes? Pretty much the only time I ever wait is complex operations on giant images. But writing those changes back to disk is in terms of ms. anything that takes milleseconds to write (or read) is not what anyone would call giant. Maybe Carlos didn't understand. My point was that people don't actually pause their work to wait for a file update to be written to disk. If they do there's something wrong. Even in the days of 300 MHz Celeron I don't remember ever having to actually pause to wait for a file to write to disk. It writes as fast as I can click the Save menu. either your files are unusually small or you aren't accurately detecting start and stop of the entire write. |
#95
|
|||
|
|||
SSDs/HDDs, memory ...
On 02/07/2020 00.32, nospam wrote:
In article , Mayayana wrote: Even if the cache is being flushed, what kind of situation would actully make people wait for disk writes? Pretty much the only time I ever wait is complex operations on giant images. But writing those changes back to disk is in terms of ms. anything that takes milleseconds to write (or read) is not what anyone would call giant. And there can be hundreds of little files to write. A file write means writing the data, then updating the metadata (timestamp, size, location), which means several seek operations per file. Yes, of course there is a cache, but it has a limit. Specially if memory is limited. Maybe Carlos didn't understand. My point was that people don't actually pause their work to wait for a file update to be written to disk. If they do there's something wrong. Even in the days of 300 MHz Celeron I don't remember ever having to actually pause to wait for a file to write to disk. It writes as fast as I can click the Save menu. either your files are unusually small or you aren't accurately detecting start and stop of the entire write. Quite so. On some situations, I can clearly hear the disk going clac-clac-clac, with the head repositioning fast, for seconds, sometimes minutes. -- Cheers, Carlos. |
#96
|
|||
|
|||
SSDs/HDDs, memory ...
"Carlos E.R." wrote
| either your files are unusually small or you aren't accurately | detecting start and stop of the entire write. | | Quite so. | | On some situations, I can clearly hear the disk going clac-clac-clac, | with the head repositioning fast, for seconds, sometimes minutes. | And how do you know that's all the one file write? Especially on 7/10. It's not easy to stop all the ludicrous background operations on those systems. and the software you're using may be accessing the disk for various things. Many progrrams now write regular backups so that they can get a file back if you crash. so it might actually be writing a second copy on a regluar basis, along with the file you intend to write. If you have to stop using the mouse and keyboard while you wait for a file to write, then you need to update from your Commodore 64. Or maybe you'll need to reconsider whether it's wise to write 1/2 GB files on a regular basis. Otherwise, you're not waiting on disk writes. Of course, there will always be cases, as you pointed out. Someone doing massve writes to a massive database, all day, every day, because that's what they do for work, will see a difference. The vast majority of people will not. I can't remember ever waiting for a file to write myself. I just tried a quick test, writing bytes to disk with no special optimizing, from a VB6 executable. (Using GetTickCount. Not the most accurate timer but good enough for this purpose.) 20million B - 125 ms 200million B - 1.2 seconds So, about 150 MB per second. That will be slightly slower with a hard disk. Maybe someone can try that. But what if it takes twice as long? That's still only 1/4 second to save 20 MB. Maybe you can blink that fast, but it's going to be perceived as instant. You won't need to stop typing to wait for the update. If you don't wait then it's instant. Nearly everything I did before getting an SSD was instant. It's all stil instant. But boot is faster, while Firefox is still a pig. |
#97
|
|||
|
|||
SSDs/HDDs, memory ...
On my desktop I've both an SSD on C: and an HDD on D:. The difference in application performance if it's installed on C or D is like night and day. The only downside to SSDs is the per GB cost. The $65.86 I paid for my new 2.5" 500GB SATA III SSD is the lowest I've paid for ANY main storage drive. |
#98
|
|||
|
|||
SSDs/HDDs, memory ...
On Thu, 2 Jul 2020 22:05:40 -0500, kelown
wrote: On my desktop I've both an SSD on C: and an HDD on D:. The difference in application performance if it's installed on C or D is like night and day. The only downside to SSDs is the per GB cost. The $65.86 I paid for my new 2.5" 500GB SATA III SSD is the lowest I've paid for ANY main storage drive. I used to pay that for 5-1/4" floppies! -- Regards, Eric Stevens |
#99
|
|||
|
|||
SSDs/HDDs, memory ...
On 2020-07-03 9:43 p.m., Eric Stevens wrote:
On Thu, 2 Jul 2020 22:05:40 -0500, kelown wrote: On my desktop I've both an SSD on C: and an HDD on D:. The difference in application performance if it's installed on C or D is like night and day. The only downside to SSDs is the per GB cost. The $65.86 I paid for my new 2.5" 500GB SATA III SSD is the lowest I've paid for ANY main storage drive. I used to pay that for 5-1/4" floppies! When I bought my first 5-1/4 inch floppy drive for my Apple II+ for $750.00 I bought a box of 10 Dyson floppies for $75.00., and my first 48 Megabyte Conner SCSI hard drive was $900.00. Rene |
#100
|
|||
|
|||
SSDs/HDDs, memory ...
On Fri, 3 Jul 2020 22:06:04 -0500, Rene Lamontagne
wrote: On 2020-07-03 9:43 p.m., Eric Stevens wrote: On Thu, 2 Jul 2020 22:05:40 -0500, kelown wrote: On my desktop I've both an SSD on C: and an HDD on D:. The difference in application performance if it's installed on C or D is like night and day. The only downside to SSDs is the per GB cost. The $65.86 I paid for my new 2.5" 500GB SATA III SSD is the lowest I've paid for ANY main storage drive. I used to pay that for 5-1/4" floppies! When I bought my first 5-1/4 inch floppy drive for my Apple II+ for $750.00 I bought a box of 10 Dyson floppies for $75.00., and my first 48 Megabyte Conner SCSI hard drive was $900.00. My first AMI 8" 5Mb hard drive was US$3,500 or thereabouts. -- Regards, Eric Stevens |
#101
|
|||
|
|||
SSDs/HDDs, memory ...
On 2020-07-04 11:38 p.m., Eric Stevens wrote:
On Fri, 3 Jul 2020 22:06:04 -0500, Rene Lamontagne wrote: On 2020-07-03 9:43 p.m., Eric Stevens wrote: On Thu, 2 Jul 2020 22:05:40 -0500, kelown wrote: On my desktop I've both an SSD on C: and an HDD on D:. The difference in application performance if it's installed on C or D is like night and day. The only downside to SSDs is the per GB cost. The $65.86 I paid for my new 2.5" 500GB SATA III SSD is the lowest I've paid for ANY main storage drive. I used to pay that for 5-1/4" floppies! When I bought my first 5-1/4 inch floppy drive for my Apple II+ for $750.00 I bought a box of 10 Dyson floppies for $75.00., and my first 48 Megabyte Conner SCSI hard drive was $900.00. My first AMI 8" 5Mb hard drive was US$3,500 or thereabouts. Now I buy 512GB NVMe drives which are the size of a stick of gum and many orders of speed faster for $119.00. Rene |
#102
|
|||
|
|||
Have hardware prices gone crazy during Covid?
On Sun, 28 Jun 2020 18:19:01 -0400
Yousuf Khan wrote: On 6/28/2020 2:05 PM, Paul wrote: Yousuf Khan wrote: On 6/28/2020 8:34 AM, nospam wrote: how wide is ultrawide? 3440 X 1440 HDMI 2 or 2.1 https://en.wikipedia.org/wiki/HDMI HDMI 2.0 is adequate for displaying 4K at 30 Hz, but you will need HDMI 2.1 for 4K at 60 Hz or higher. Perhaps DP 1.2 ? Tables here are less useful. https://en.wikipedia.org/wiki/DisplayPort The problem is, the entry level video cards now are pretty expensive. And even if you could find an FX5200, it wouldn't have the output :-) Nvidia's website lists the maximum resolution of its cards easily. AMD is less useful. Yousuf Khan just don't buy from china. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|