A first look at NZFS and replacing unRAID with NZFS’s Transparent RAID (tRAID)

spectrumbx

[H]ard|Gawd
Joined
Apr 2, 2003
Messages
1,647
Hey guys! :)

I had to take a break from the heavy coding to announce NZFS.
NZFS stands for Next-Generation Zion File System.

More detailed information will be provided in the weeks to come as NZFS is currently in private beta testing.
Nonetheless, here is a first look: http://www.openegg.org/2013/02/12/a...ing-unraid-with-nzfss-transparent-raid-traid/

Taking the use case approach
NZFS is vast in features so much so that we will approach each feature as a use case in order to avoid overwhelming the potential user.

Use case 1: Using the Transparent RAID feature of NZFS as a replacement for unRAID
Transparent RAID
Imagine a RAID system where you can take any one drive from the RAID and have that drive fully readable in another system without the other drives part of the RAID.
Then, imagine a RAID system where losing more drive than the tolerance level will not cause you to lose all your data beyond the drives lost.
Well, it is here. NZFS’s tRAID: a Storage Technology Breakthrough. :)

Transparent RAID has the following features:
  • Independent disks with transparent dedicated parity
  • Can tolerate X drives failures, where X is the number of drives the user has configured for parity.
  • Each drive can be formatted with its own independent file system.
  • Each drive can be pulled and read in another system by itself.
  • In case of failure past the tolerance level, surviving drives are fully readable/writable.

tRAID vs unRAID
Transparent RAID is a better version of unRAID that runs on any modern version of Windows and Linux.

Advantages over unRAID:

  • Multi-Parity support
    - Running a large array with just one parity is simply foolish. unRAID is limited to one parity drive.
    - Hard drives tend to fail in batches and we tend to buy drives in lots, which almost always come from the same batch.
    - When you lose a drive, chances are great that you might lose another drive shortly after if they are all from the same manufacturing batch.
    - Worst, RAID recovery tend to put greater stress on your drives and that’s the time when another drive might fail.
    - Improve your protection level and recovery chance by using two or more parity.
  • Support for drives with existing data
    - Outside of FlexRAID's RAID-F technology, NZFS's tRAID is the only other system on earth to support creating a RAID array using drives with existing data on them.
    - tRAID also supports adding drives with existing data to an existing RAID.
    - Other RAID systems (including unRAID) will format all your drives before adding them to the RAID. This means, you need to have another storage array with enough space to copy your data to and from. This create additional cost (you have to buy more drives to temporarily hold your data) and additional time (the time to copy the data out and back in).
  • NZFS runs on any modern Windows or Linux OS
    - unRAID runs on a non-standard OS and users are limited to the hardware its customized OS supports.
    - By running on your favorite OS, NZFS let’s you build a storage box that can run other applications such that you have a more complete and usable system.
    - These value added applications are essential to running an effective storage box.
  • NZFS is more future proof
    - The day the developer of unRAID is no longer able to support new hardware, you are stuck.
    - With NZFS, you can upgrade your hardware as your favorite OS evolves.
  • No cache drive required with tRAID (no gimmicks)
    - unRAID requires you to add a cache drive (along with all the many issues that go along with that) in order to achieve adequate performance.
    - No such thing with NZFS. An NZFS Transparent RAID use no gimmicks and has high performance out of the box. No cache drive. No additional way to losing your data.
    - A cache drive as used in unRAID leaves your data vulnerable! Yikes!
  • Rich UI
    - The client application for managing your NZFS hosts is a very rich and slick UI that makes management a breeze and keeps you from making mistakes. There is nothing more frustrating than something that is cryptic to manage or a UI that can lead you to doing the wrong thing and lose your data in the process. Taking cues from the interface we designed for FlexRAID, the NZFS client interface is a fresh and intuitive new approach.
    - You time is valuable. The NZFS UI keeps it simple for users that want simplicity while giving users that like to tinker something to tinker with.
    - A single client install can manage an unlimited number of hosts.
    - unRAID relies on its user community to create unsupported UI plugins to restyle the default UI into something usable. Managing your precious data with an unsupported UI modification? Yikes!
  • NZFS is far more innovative
    - Remember that it is only one feature of NZFS that is a complete and better replacement for unRAID. When you add the many other features, you start to realize that the people behind NZFS have a far greater expertise in storage technologies.
    - unRAID is struggling to innovate and is frankly dépassé.
    - The people behind NZFS are true storage data architects with advanced mathematics knowledge unlike the guy behind unRAID who was just lucky to turn some free open source code he found into a product.
    - It is our belief that he does not truly understand the free code he has in order to innovate past what was implemented for him.
    - Who do you want to invest into? The innovative architects who understand and are implementing every facet of their products from the ground up or the guy with the free code he can’t really improve?
  • Our innovative minds think completely outside of the box.
    - When we first released FlexRAID with its RAID-F approach (RAID over File System), people were thinking it was because we could not implement standard RAID.
    - It took time for the community to catch up and understand the real value in the RAID-F approach to data protection.
    - Standard RAID is trivial for us to implement and we don’t do the “me too” thing unless we bring something more to the table.
    - Our products are either a complete departure or a vast improvement over what is already out there. Otherwise, why bother?
  • Note that unRAID is a very small fish to fry in NZFS’s quest for dominance (still, small fish get fried first).
    - NZFS is really going after ZFS and products from Data Robotic, NetApp, Synology.
    - unRAID just happens to be a small and unfortunate roadkill.

We brought you Snapshot RAID & RAID-F (others tried to copy), Storage Pooling (others copied), and now we are bringing you NZFS.
Can the copycats keep up?
Intrigued yet? Well, we are just getting started.

NZFS is currently in private beta testing.
 
sounds great but unless im missing something snapraid can pretty much do all of what it says (especially in the comparison with unraid) ..?
 
Yeah, there is a lot of hype but little real information.

The interesting comparison would be NZFS vs. FlexRAID and SnapRAID. What does NZFS bring to the table?
 
sounds great but unless im missing something snapraid can pretty much do all of what it says (especially in the comparison with unraid) ..?

Yeah, there is a lot of hype but little real information.

The interesting comparison would be NZFS vs. FlexRAID and SnapRAID. What does NZFS bring to the table?

Sorry guys, but I think everything just went completely over your heads.
It is most likely my fault for either bombarding you with too much information or not providing contextual clarity. :eek:

Just take the time to read things more carefully on the blog post.

Key points though:
1. NZFS is vast and only one of its features is being touted as a replacement for unRAID.
2. NZFS is going after ZFS with its RAIDz.
3. FlexRAID is RAID-F (RAID over File System) while NZFS is RAID under and within File System (each approach has its value)
4. NZFS is not a replacement for RAID-F (they might compete in some fronts, but they are catered to different niches)

The goal is to get NZFS to the enterprise market but to test-bed it in the enthusiast arena beforehand.

For this forum, I think the tRAID feature is of initial importance. The other features will be discussed later.
 
Sorry guys, but I think everything just went completely over your heads.
It is most likely my fault for either bombarding you with too much information or not providing contextual clarity. :eek:

It certainly did not go "over my head". If anything, it went under my feet. You still have not provided any salient details about the features and capabilities of NZFS. You are just hyping it without any useful information about it.

If you have any real details, you should write them out. If you do not, you should wait until you do before posting, since this kind of empty hype does not help your product's reputation.

1. NZFS is vast and only one of its features is being touted as a replacement for unRAID.
2. NZFS is going after ZFS with its RAIDz.
3. FlexRAID is RAID-F (RAID over File System) while NZFS is RAID under and within File System (each approach has its value)
4. NZFS is not a replacement for RAID-F (they might compete in some fronts, but they are catered to different niches)

1) "vast" : what does that mean? you have written many lines of code? that is useless information to us
2) "going after" : I assume you mean improving on...in which case, how is NZFS improving on RAIDz, exactly?
3) "under and within" : What does this mean exactly? What is the "value" of it, exactly?
4) "not a replacement" : Rather then telling us what NZFS is not, why not tell us what it is, exactly?
 
The key feature of ZFS is data integrity, not RAID-Z.

Indeed. Please read the full blog post.
I have not described yet the file system part as, for this use case, I am first introducing the RAID part.
On the file system part, the comparison will be made directly against ZFS.

So, tRAID vs unRAID and NZFS vs ZFS.
Right now, I am only doing tRAID vs unRAID.

It certainly did not go "over my head". If anything, it went under my feet. You still have not provided any salient details about the features and capabilities of NZFS. You are just hyping it without any useful information about it.
...
As charged. My fault for the lack of clarity. :eek:
So, whether it be your feet or your head, the statement wasn't a jab and I could stand to re-write it to mean that I failed to provide you with enough clarity.

I am an application architect and not PR person and so forgive me on how that might have come across.

The information provided so far is indeed partial and it will take several blog posts and a bit of documentation to fully describe NZFS in details.

What I am trying to do here is introduce NZFS in bits and pieces so that things are easier to digest; and hence, the use case approach.
 
Last edited:
...
1) "vast" : what does that mean? you have written many lines of code? that is useless information to us
2) "going after" : I assume you mean improving on...in which case, how is NZFS improving on RAIDz, exactly?
3) "under and within" : What does this mean exactly? What is the "value" of it, exactly?
4) "not a replacement" : Rather then telling us what NZFS is not, why not tell us what it is, exactly?

The point of this post (believe or not) was really to drive you to have questions. So, great that you have some. ;)
Trying to explain NZFS in one post would be like trying to explain ZFS in one post.
NZFS will take time for everything to make complete sense and hence why I am announcing it before it is actually released.

1. Vast as in features and what you can do with it. Some you might care for, others you might not.

2. NZFS (the file system + RAID) is attempting to present itself as a replacement for ZFS + RAIDz (but I am not discussing that part yet - a blog post will be made later on that).
One feature, however, which I call Transparent RAID (tRAID) is something I want to start a discussion on now.

3. Later on this one when I am ready to discuss the file system part.

4. Trying to... I am first trying to pick your interest before I go into further details. :)

Last, part of my post is to start a mini flame war. This worked on AVSforum, but not here yet. :(
 
Looks good from the feature list but so did windows storage spaces and that ended up bunk. Until you can get a trial up I will reserve judgement. If it is as robust as you are saying then keep up the good work.
 
It's a pretty tough crowd here compared to other sites like servethehome and even AVSforum. There is little humor here and everyone is impatient. :eek:

I patiently await more information. :)
 
The point of this post (believe or not) was really to drive you to have questions.
Here's a few for ya. Just skimmed the OP, so I may have missed the answers.

1) Can you expand a raid array a single drive at a time?
2) Do all drives need to be spun up in order to access the data on the array, or just the drive(s) that contain said data?
3) What happens when the power goes out during a write?
4) Can I pull three drives out of the array, connect them to different controllers, and have them all be re-imported into the array correctly, or are the drives controller dependent?
5) Can the raw drive pool be split into multiple subpools/LUNs?
6) How is the speed vs. your competitors?
7) Is array metadata stored on the array or on the host? (eg. Can I take the array out, put it in another box, and have it function perfectly without any new configuration?)
 
Seems like an interesting product. I will say thought that the tone of your comparasin makes it seem very unprofessional and really takes away from your product....

I read the blog post and it seems all the information that I would want to know is comming in a future post such as:
  • How NZFS can give you the advantages of different kinds of raid levels in regards to data protection and performance, all within the same grouping of disks
  • Details on the file system that it can use optionally with copy on write, etc.
  • How NZFS's raid is an improvement over standard raid levels
  • How this will work for energy conservation (i.e. spins up only the disks that contain data you need)
  • Details on if tRaid will support the advantages listed in bullets 1-3 above

Which is disapointing.... hopefully more info is released soon.....

I would also love to see a performance comparasin of this VS raid-Z pools and information on how auto-healing would work if you combined NZFS with ZFS, as I believe the self-healing abilities of ZFS require a ZFS parity drive to regen with (I suppose you could regen the file with the NZFS parity assuming that it didn't calc parity on the bit-flipped data).

How much will a licence cost for home use? Will it be based on a per capacity basis or on a per server basis?
 
@Scout255
I understand you wanting to know more on the file system part.
But as stated, that's for later. For now, it is all about tRAID.
No comment on cost either for now.

Here's a few for ya. Just skimmed the OP, so I may have missed the answers.

1) Can you expand a raid array a single drive at a time?
2) Do all drives need to be spun up in order to access the data on the array, or just the drive(s) that contain said data?
3) What happens when the power goes out during a write?
4) Can I pull three drives out of the array, connect them to different controllers, and have them all be re-imported into the array correctly, or are the drives controller dependent?
5) Can the raw drive pool be split into multiple subpools/LUNs?
6) How is the speed vs. your competitors?
7) Is array metadata stored on the array or on the host? (eg. Can I take the array out, put it in another box, and have it function perfectly without any new configuration?)
1. Yep. And not just one drive at a time but also multiple drives at once expansion is also supported. As posted on the blog, you can even migrate between RAID types in place.

2. With tRAID and a few other RAID types, only the accessed drive needs to be spun.
For the other types, all drives spin.
Basically, the RAID portion of NZFS has RAID implementations geared toward energy saving and others geared toward speed.

3. Same things as with all RAIDs without BBU. :p

4. The drives are controller independent. They are also independent of their positions on the controller.

5. Yes. You can do anything you can normally do to any raw drive including partitioning, etc.

6. NZFS is entirely written into the kernel with near zero locking. Benchmark will come soon. I intend for this to be the fasting thing around. ;)

7. Yes, you can take the array out and have it running in another system with minimal fuss (after you confirm that everything is correct - human validation is required).
 
Seems like an interesting product. I will say thought that the tone of your comparasin makes it seem very unprofessional and really takes away from your product....
...
Something else I meant to address.
I am introducing the product to a group of enthusiasts just so that I can have a certain freedom, which I would otherwise not have if presenting it at an enterprise level.

You've got to loosen up guys.
I know humor is a slippery thing, but my current conversation style is meant to be tongue and cheek. :D

Plus, if I was to take myself too seriously, I wouldn't even be talking to you little people.
You would be talking to my VP of Marketing (whoever that is). :p

Before it goes to the masses though, most of the rough marketing/presentation edges will get polished (somebody else more qualified to the task will take on that duties).
 
High ambitions indeed. I hope you succeed. Until someone presents a safer solution (with research from comp sci professors as ZFS has) I will stick to ZFS. But if it turns out that your solution is better than ZFS, I will switch. But you need researchers inject bad artificial data all over the disks, and your solution must recover from everything. Not many filesystems (except ZFS) can do this:
http://www.zdnet.com/blog/storage/how-microsoft-puts-your-data-at-risk/169
So, if you rely on Windows filesystems which can not recover from errors as shown in the link - you are toast. You should avoid all Linux and Windows filesystems - read the link.

Even if you dont succeed, the world needs more people that try crazy ideas, instead of "no it cant be done, better dont try".
 
I have read your blog post. How can you claim that you have "data rot detection"? Have you read the research from CERN? It does not suffice to add checksums. Hard disks have checksums riddled everywhere. 25% of the disk surface is error correcting codes aimed to detect and repair data, and still we see data corruption on disks. It does not suffice to add checksums. What do you do with ghost writes, for instance? Read the research on data corruption. It is very difficult.

It is like designing a safe crypto OS, it does not suffice to add RSA or Diffie Hellman and claim it is safe. The entire OS must be designed from ground up. Crypto can not be added afterwards, it must be designed for it. It is like using and trusting NTFS (which is proven unsafe in research) and then claim that your solution togehter with NTFS is safe. This is plain wrong. Where is the research that data rot is detected? Have researchers tested it? No? Then you should remove "datarot detection", otherwise your users will be fooled.
 
I have read your blog post. How can you claim that you have "data rot detection"? Have you read the research from CERN? It does not suffice to add checksums. Hard disks have checksums riddled everywhere. 25% of the disk surface is error correcting codes aimed to detect and repair data, and still we see data corruption on disks. It does not suffice to add checksums. What do you do with ghost writes, for instance? Read the research on data corruption. It is very difficult.

It is like designing a safe crypto OS, it does not suffice to add RSA or Diffie Hellman and claim it is safe. The entire OS must be designed from ground up. Crypto can not be added afterwards, it must be designed for it. It is like using and trusting NTFS (which is proven unsafe in research) and then claim that your solution togehter with NTFS is safe. This is plain wrong. Where is the research that data rot is detected? Have researchers tested it? No? Then you should remove "datarot detection", otherwise your users will be fooled.

ZFS protects against bit-rot.

ZFS data integrity
For ZFS, data integrity is achieved by using a (Fletcher-based) checksum or a (SHA-256) hash throughout the file system tree.[35] Each block of data is checksummed and the checksum value is then saved in the pointer to that block—rather than at the actual block itself. Next, the block pointer is checksummed, with the value being saved at its pointer. This checksumming continues all the way up the file system's data hierarchy to the root node, which is also checksummed, thus creating a Merkle tree.[35] When a block is accessed, regardless of whether it is data or meta-data, its checksum is calculated and compared with the stored checksum value of what it "should" be. If the checksums match, the data are passed up the programming stack to the process that asked for it. If the values do not match, then ZFS can heal the data if the storage pool has redundancy via ZFS mirroring or RAID.[36] If the storage pool consists of a single disk it is possible to provide such redundancy by specifying "copies=2" (or "copies=3") which means that data will be stored twice (thrice) on the disk, effectively halving (or, for "copies=3", reducing to 1/3) the storage capacity of the disk.[37] If redundancy exists, then ZFS fetches the second copy of the data (or recreates it via a RAID recovery mechanism), and recalculates the checksum—hopefully reproducing the original value this time. If the data pass the integrity check, the system can then update the first copy with known-good data so that redundancy can be restored.

http://en.wikipedia.org/wiki/ZFS#Data_integrity
 
@brutalizer
You mean to tell me that a guy who is going after an existing product hasn't read on how such existing product does things? :eek:
 
I'm very interested in NZFS and cant wait to see the results and such once it comes out.

As a current FlexRAID user I love the current system as it works for me and my data storage type and uses. However I do wish I could move to a real-time RAID solution and I'm just not comfortable with FlexRAIDs current realtime RAID implementation.


What I love about FlexRAID is that I can add in disks of any size even if they contain data and that I can take disks out and use them in another system independently. I like that I can simply maintain and grow once single large storage pool. I also love that I can use as many parity disks as I want as my array grows.

I'm glad to see that tRAID still has support for all these features as well as the addition of stable realtime raid.
 
I have read your blog post. How can you claim that you have "data rot detection"? Have you read the research from CERN? It does not suffice to add checksums. Hard disks have checksums riddled everywhere. 25% of the disk surface is error correcting codes aimed to detect and repair data, and still we see data corruption on disks. It does not suffice to add checksums. What do you do with ghost writes, for instance? Read the research on data corruption. It is very difficult.

It is like designing a safe crypto OS, it does not suffice to add RSA or Diffie Hellman and claim it is safe. The entire OS must be designed from ground up. Crypto can not be added afterwards, it must be designed for it. It is like using and trusting NTFS (which is proven unsafe in research) and then claim that your solution togehter with NTFS is safe. This is plain wrong. Where is the research that data rot is detected? Have researchers tested it? No? Then you should remove "datarot detection", otherwise your users will be fooled.

Oh boy
 
What I love about FlexRAID is that I can add in disks of any size even if they contain data and that I can take disks out and use them in another system independently.


How often do you do this? :confused:

Because I've never had a need to do that in my entire life.
 
I noticed your second blog post and it mentions that in order to recover a file you would need to resilver / recover (or whatever the proper terminology is with this new raid method) the entire disk in order to recover the damaged data? Does this apply if your reading a file and your hard drive as an unrecoverable read error? What would happen if one of the other disks has an URE during the resilver in a different data location than the first?

Ref: http://www.openegg.org/2013/02/21/flexraids-raid-f-vs-nzfs/ under "Support partial data recovery?" - "No - All or nothing" and under "Recovery of specific files" - "No, only recover a whole drive. Has no concept of files."

Seems to be quite a disadvantage if I'm understanding this right (which hopefully I am not). I believe with other RAID methods, URE's wouldn't cause an entire disk resilver and a resilver would only be required on a complete disk failure, or am I understanding this incorrectly?
 
How often do you do this? :confused:

Because I've never had a need to do that in my entire life.

To quote myself from another post:
I think the most pertinent argument about being able to support drive with existing data is that it is:
- cheaper
- and allows you leave the RAID implementation for something else very easily

With RAID-F or tRAID, users are not locked in. They can pull their drives out and that would be the end of it. No trace of RAID-F or tRAID (hum, I should rethink that - lock them in... lock them in... :p).

Now, let's take a case where a user needs to migrate 10TB of data into a new RAID.
The user can bring his/her drives with data as-is and create the RAID under RAID-F and tRAID.

Compare that to having to have another 10TB of space somewhere where to first copy the data, format the drives, initialize the RAID, and finally copy the data into the new RAID.
Such migration would require 20TB worth of drives.

Things change. Today RAID-F is cool, tomorrow it is NZFS... and the day after that is its XYZ.
You just can't hate flexibility. :)

Now, I have had plenty of cases where I took a drive out to another system to back it up faster or transfer some data faster.
 
I noticed your second blog post and it mentions that in order to recover a file you would need to resilver / recover (or whatever the proper terminology is with this new raid method) the entire disk in order to recover the damaged data? Does this apply if your reading a file and your hard drive as an unrecoverable read error? What would happen if one of the other disks has an URE during the resilver in a different data location than the first?

Ref: http://www.openegg.org/2013/02/21/flexraids-raid-f-vs-nzfs/ under "Support partial data recovery?" - "No - All or nothing" and under "Recovery of specific files" - "No, only recover a whole drive. Has no concept of files."

Seems to be quite a disadvantage if I'm understanding this right (which hopefully I am not). I believe with other RAID methods, URE's wouldn't cause an entire disk resilver and a resilver would only be required on a complete disk failure, or am I understanding this incorrectly?
I removed that as it is indeed confusing.
Being able to recover specific files covers the point I was really trying to make in favor of RAID-F.

If a drive fails under tRAID, the data is reconstructed live (degraded RAID).
If you sustain a failure past the tolerance level, you will lose the failed drives. All other drives, will be fully readable/writable.
 
To quote myself from another post:


Now, I have had plenty of cases where I took a drive out to another system to back it up faster or transfer some data faster.


Did you put it back when you were done?

I hate it when people don't put my Creedence tapes back where they're supposed to go, and I wondered how much time you saved over a sequential read + write from/to a single disk across your transport?
 
Last edited:
Did you put it back when you were done?

I hate it when people don't put things back where they're supposed to go, and I wondered how much time you saved over a sequential read + write from/to a single disk across your transport?
Of course. :)
Forgot to mention that I take some of my drives to a friend's house where I back them up a few times a year too.

For my particular case, time is of essence and I need my backup tasks to execute quick.
I usually take multiple drives out and backup them up in parallel.
 
Of course. :)
Forgot to mention that I take some of my drives to a friend's house where I back them up a few times a year too.

For my particular case, time is of essence and I need my backup tasks to execute quick.
I usually take multiple drives out and backup them up in parallel.

I heard this is how FedEx has a higher data transport capability than the entire Internet.

I like rsync, dd, or ZFS send when I don't have to think about scaling, but everyone's different.

It still sux when I can't find my Creedence tapes because someone borrowed them. :mad:
 
This sounds interesting, I look forward to testing it. How long do you think it will take before you'll have a version available?
 
I removed that as it is indeed confusing.
Being able to recover specific files covers the point I was really trying to make in favor of RAID-F.

If a drive fails under tRAID, the data is reconstructed live (degraded RAID).
If you sustain a failure past the tolerance level, you will lose the failed drives. All other drives, will be fully readable/writable.

Ah, good news. That makes much more sense.
 
ZFS protects against bit-rot.
Yes, so what?


@brutalizer
You mean to tell me that a guy who is going after an existing product hasn't read on how such existing product does things? :eek:
I dont understand what you mean. In my references, there is a PhD thesis that explains that NTFS, ext3, etc is not safe. And CERN says that it does not suffice to add checksums to make a safe storage solution.

Your solution is using NTFS + checksums, and you claim your solution is safe? Against all research?
 
**Deleted**.....

oh Girl. why you looks angry and dissatisfied by mentioning your degrees?

I have master degree in Computer Science, and dual undergraduate degree in Computer Science and Electrical engineering .
Should I mention my degree to make everyone look at me when discussing or sharing ideas/information.

I never mention my degree mostly, actually would mention during job interview :D when asked.

reading white/research papers can be done with everyone.
everyone has his/her own perception on what to do in data corruption, not everyone agree to only one idea/research.
listen, digest, and filter certain information to rich everyone knowledge

if you have master degree, "f**k up " word is not easy to get out from your action.
as I know during graduate study, we learn focusing to analyze and make hypothesis to tackle current and future research/issue.

ok back to the topic.
 
Last edited by a moderator:
Cantalup, you know nothing of our earlier history, ok? That idiot Odditory has said things to me earlier, and for that, he apologized to me, agreeing he did wrong. Now he is doing something similar to me, again. I will accept his apology once, but not again. So I suggest you stay out of this.

The reason I mention me degrees, is because he is implying I know nothing. I am trying to show him that I am knowledgeable and read lot of research papers. That I know what I speak of. He never refers to any research papers, so obviously he doesnt know too much.



What did you do your M Sc in? I did complexity theory and discrete math, for my M Sc in comp sci. My M Sc in math was in applied/pure math. BTW, I also have to undergrad degrees. And two masters.
 
Brutalizer,

You know, this type of language is completely uncalled for. I sure nobody wants to here this kind of language. If you have a problem with his response please take it to PM.
 
If you have a problem with his response please take it to PM.
This. There is a certain degree of respect required in public postings between users on this forum. I'm not a moderator, but I would say that your post has overstepped your bounds. Specifically, I would like to point out this section from the rules:

(1) Absolutely NO FLAMING, NAME CALLING OR PERSONAL ATTACKS. Mutual respect and civilized conversation is the required norm.

That being said, I am interested in reading more about the checksum vs. bit rot debate. Do you have any links you could direct me to?
 
Back
Top