Barziya

That "thing" may be affecting the write mode too -- it may not be writing the pattern to every single byte of the destination file. I believe it has more to do with calculating blocks based on a size and only reading a specific amount of those blocks. Anything at the end, is not read and ignored. That is too bad! I had very high hopes for badblocks. See, I was investigating alternate ways to do a preclear, before Google brought me to this thread here. The thing that started me was the sum command preclear uses for the post-read, which is a very very slow way to do that. I might as well capture and parse the output of a `hexdump /dev/sdX | head` and do the job five times faster. At the end, I narrowed down my choices to cmp and badblocks. I especially liked badblocks for its -d option (read delay factor) which could make the system more responsive dirung a long-running preclear. It's too bad I can't rely on badblocks to go through every single byte on the disk, that's a show-stopper.

That "thing" may be affecting the write mode too -- it may not be writing the pattern to every single byte of the destination file.

This is an interesting issue. Perhaps the pattern is not actually tested/compared and is only returning success if the read returns success. No, when I ran the same test with a different pattern, it immediately started showing errors. Only the test with the zero pattern passed. I don't have that disk anymore, but I found a way to reproduce a similar thing on a file. Consider this: # dd if=/dev/zero bs=1M count=100 of=zeros 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.595489 s, 176 MB/s # # cmp /dev/zero zeros cmp: EOF on zeros # # badblocks -vs -t0 zeros Checking blocks 0 to 102399 Checking for bad blocks in read-only mode Testing with pattern 0x00: done Pass completed, 0 bad blocks found. (0/0/0 errors) # # echo crap>>zeros # # cmp /dev/zero zeros /dev/zero zeros differ: byte 104857601, line 1 # # badblocks -vs -t0 zeros Checking blocks 0 to 102399 Checking for bad blocks in read-only mode Testing with pattern 0x00: done Pass completed, 0 bad blocks found. (0/0/0 errors) #

I wrote all zeros to a disk, then intentionally wrote a few non-zero bytes here and there. To my dismay, a read-only badblocks pattern test for zeros passed with flying colors: Checking for bad blocks in read-only mode Testing with pattern 0x00: done Pass completed, 0 bad blocks found. (0/0/0 errors) Yet, I could hexdump the disk and see the non-zero bytes.

If that statistic was true, that would mean that about 850 members of this forum are browsing here without Javascript. What is your point? Cut them off? Some people have very low patience for web pages that take forever to display, and that require tons of memory, not to mention crap like cross-site scripting, tracking, popups, and so forth. It has occured to some people that they can set up a system which is not so easy to infect, and which does not crash and burn four times a week. It's a revolutionary thought, I know, but computers can be used for things other than just reinstalling the os over and over again.

You can call it false or whatever, but let me ask you something. My laptop, (nlite XP Pro SP3), which I use 12 hours a day, hasn't rebooted since October 2012. (I put it in S3-sleep occasionally). What is your uptime?

You miss the point.

I feel sorry for you. My browser will run circles around any browser you are using.

Which brings me to my biggest issue with the v5 GUI: To this day I browse the Internet without Javascript. (my browser is Pale Moon version 3.6.32 + NoScript plugin). Only for UnRaid I am forced to use a separate Javascript-enabled browser, which honestly annoys me to no end. I've thought many times that I should probably look into writing my own simple interface to UnRaid when I have a little time on my hands. So you password protected your gui, so what? Once you log into the gui, you give right to all the scripts that are running inside the browser to do whatever the hell they want.

nars, I agree with your posts. Only your supposition made me laugh. Suppose Tom plans to disappear again for a few years. I see that you're new here.

+1 (Personally, all I ever wanted from a GUI was in the 4.7 GUI. I don't much care for JavasScript enabled browsers.) LOL I'd go even further. I just dug out an old server running code from 2006. The webGui used HTML framesets to make boxes (not to be confused with frames). Used a simple parser I coded in about 5 hours. Blazing fast. Just the vital info - virtually no css or javascript, no jquery libraries and plugins, no dropdown boxes, no accordion affects, etc etc. Nothing wrong with that. And nothing to laugh at either. I for one would be a very happy if I had the option to use that GUI. They might as well say the grep command "looks so old" for what I care. Hey, you're the boss, you know what's best. It just gives me the feeling of terrible loss when popular demand wastes your time on the webGui, when you could be playing with serious things, like double-parity, 64-bit builds, etc., etc..

+1 (Personally, all I ever wanted from a GUI was in the 4.7 GUI. I don't much care for JavasScript enabled browsers.)

no? Wouldn't you rather have a LTS kernel, than a EOL kernel? (It's not like we haven't waited a few years for a final, I'm sure you can survive if you'll have to wait an extra week or so.)

Since that was posted, 3.10 has gone to stable 3.10.4, and 3.9 has been labeled EOL. Now it seems reasonable to entertain this idea.