Messages posted by: NLS

Ah, great.

So can someone else verify that this thing works on Windows kernel 6.1 SP1 x64? (Windows 7 or better Window 2008R2)

So Brahim did you check out the logs?

Thanks. Anyone else?

No opinion anyone?

I am using firefox 5 and no its not a compatibility issue.
It's a functionality issue.

Well I didn't find exactly the files wiki mentions but here is what I have...

(btw I already have 20 log.log historical files!)

OK I defined a storage pool in beta10 like this:

Name Pool-Q
Unique Volumes E:\;F:\;G:\;H:\;I:\;J:\;K:\;L:\;M:\
Threads 5
I/O 1MB
Reserv 3GB
Removable true
Auto-Folder-Priority
Drive letter Q

Publiushed/Started... seems to have finished this step (start is ghosted, stop is clickable) ...but in reality no drive Q or anything...

I rebooted just in case...

After reboot it crashed because I saw the "FlexRAID desktop" page but some com.google.something error popped in the FlexRAID pop-up system which I didn't have a chance to grab and no icon on the desktop or any item in FlexRAID "start menu". Then it crashed, no web page and service "FlexRAID" was stopped. I manually started it and page was ok this time.

No drive Q, at all. Ever.

So am I missing something? I remember there were a couple of patches for x64 before (why activated using CLI), but now?

Remember SBS2011 SP1.

I remember in older betas that I could define, a folder pool to merge in the same window that I could build the parity configuration - just different tab.
I cannot find this now. Is it on purpose or a bug?

The proper way now, is to make a separate "icon" (different pool?) that describes the merge?

Let see this scenario. I'll present my own setup but it possibly applies in general.

My disks are like this (I show real disk sizes on purpose):
P: and E: 931GB (2)
F: and G: 698GB (2)
H: to M: 465GB (6)

Current setup is like this:
P: PPU1
E: DRU1
F: DRU2
G: DRU3
H: + I: DRU4
J: + K: DRU5
L: + M: DRU6

I am thinking of "switching" to this (will change letters but now keeping the same so no to confuse you):
H: + I: PPU1
P: DRU1
E: DRU2
F: DRU3
G: DRU4
J: + K: DRU5
L: + M: DRU6

As you can see the number of DRUs remains the same. Available storage also.
BUT
I have one less DRU consisting of a set of two disks and instead have a PPU that has this "dual" setup.

As a user (and without using any "JBOD" functionality yet) my immediate gain is that I have less actual data drives (more contiguous and less actual storage units). Nine vs. eight.
Also this becomes stronger and it will have a greater effect on my next drive purchase (see below) *.

But what is the effect of this change to performance?
Both for snapshot and real-time.
Brahim (or anyone else), any ideas?

---
(*)
Concerning next drive purchase. If my next drive is a 2TB (which has the price sweet spot currently) and assuming I cannot add more drives, so I will replace one of the small ones. Then with the CURRENT setup/old philosophy, it means:
1) Move previous parity to become a data disk.
2) The new disk (1862GB) will become new Parity.
New DRUs will be like this (still keep same letters so not to confuse):
(M: new disk) PPU1
P: + E: DRU1 (1862GB)
F: + H: + I: DRU2 (1628GB)
G: + J: + K: DRU3 (same)
L: DRU4 (tiny 465GB)
--OR (better)--
(M: new disk) PPU1
P: + E: DRU1 (1862GB)
F: + G: + K: DRU2 (1861GB)
H: + I: + J: + L: DRU3 (1860GB)

While by following the kind of setup I am now thinking, then:
1) The new disk would replace one of the six 465GB disks...
2) but I would need to take two more off to become parity
So it would be like this...
H: + I: + J: + K: PPU1
(new disk M

DRU1 (1862GB)
P : + E: DRU2 (1862GB)
F: + G: + L: DRU3 (1861GB)

Still same number of (reduced) DRUs, but second option (parity mixed grill) gives even less and larger contiguous data disks), six vs. nine.

I haven't calculated the effect this will have when I have to start removing 465GB disks even from the parity to actually replace them with larger (as still I will try to eliminate disks based on their size)... because with the "new" setup, I have just one remaining DATA 465GB disk.

But the performance question remains and is the deciding factor. So anybody has any opinion on this?

I know I am not writing (and will not change that), but because I am using the product I have two questions:

1) furry dad (?), do you have any solution for this working without having to logon? (headless server)

2) Brahim, what is the official status of this (as of latest 2.0 build). Does sharing from (and from and to) x64 work without manual workarounds?

I think it's better for both sides to stay apart at least for some time.

---

Maybe by the time I get back, if I get back, you'll have implemented implicit merge.

...

...

...

(ok that was a joke if someone can understand a joke)
(not the stay apart part, that was no joke)

I know I said I wouldn't be posting any more but I have to say this simple statement:

FYI my post was not meant as palmano quoted it and you read it. I am saying this directly, so it is not a matter of how you interpret it. How you guys took it, is not how I meant it. I am saying this directly and let this be my last word.

Keep up the good work. I don't plan to intervene... even with simple phrases like the above.

I didn't have a different example readily available. Served as an example. If someone ele wrote that post, would probably give an different example, about something he knows about.

Anyway. Your point probably came through (contrary what mine does every time), so if someone else has something to say...

(I won't even respond as I already told Brahim, I won't be posting here any more - be good everyone

)

Thank you for your reply.

First of all, of course I am just another user. Never said something else. Don't say things I didn't say.

People reading how this project evolves, doesn't tag them as having faith in the project, nor does it mean that they have time or care to make this go forward. The people that do, are as I said very few.

My posts are not "insulting" in any way, although I have received insulting reactions (that I did look the other way). Some of my posts I am sure COULD be read like that because of the language barrier. Could - possibly. Yet, I don't think because I am extra careful.

If you cared to notice, I made this post in reaction to Brahim's insulting reaction on... erm... another post of mine THAT DID NOT HAVE ANYTHING to do with any "repeated request" of mine. In fact after some recent PMs between me and Brahim, I didn't even plan on repeating my implicit merge request and I HAVE followed that actually. So let's not just generalize to mark me as bad eh? Not nice.

In any case thank you for your post. Keep them coming. It's the off topic section after all.

EDIT: BTW, the current forum system is known to keep users online even after they have left. Just so you have a better idea of the statistics you present. Just mentioning.

Now it was my turn to get angry. My post/comment/whatever you name it Brahim, was not worthless.

And I didn't ask you to do anything (at least about your hated implicit merge).

It seems to me there are two, three, maybe four people with faith in this project right now (not including you). I am one of them (strangely enough after all this).
But if you insist on treating mine (and potentially other people's) CONSTRUCTIVE comments like that (actually US stupid morons spending time to help YOU make this thing better - you DO realize our time is also expensive, or don't you), I am sure you'll make a great FlexRAID just for yourself.
OK I realize this might not touch you a bit. You decide about that.

Let's not get started on who's time costs how much. If I wanted to hire a programmer to do something for me (setting aside that I already have a team), I would at least ask someone who doesn't insult me and devaluate my good will on trying to actually help him and the time I spend for this.

My post is up there for everybody to see. It's easy, you people go and visit the live beta testing thread and see how worthless my posts are. If anybody else believes that post was worthless, let me know. Not in PM (like other times), in public in this thread. I can take it.

Unbelievable.
Internet is big but unfortunately seems, not big enough.

Unbelievable Brahim. Really. I will not ruin this thread. Will post in off topic.

ON topic.

CG2010 idea is good actually if the move process is asynchronous to the rest and delayed. This will not create any 15 minute freeze.

On the other hand, Brahim is also right in that the whole thing creates possibly an unnecessary thread of I/O actions. A file goes to a temp position (the disk with largest space serving as cache), then the system decides where the file SHOULD go, schedules a move, does it over the "view" so that parity gets updated. Some food for thought thought though: (1) I think I remember that moving a file around (not changing it) used to NOT mess parity. Did this change in "live" version? (2) Actually statistically there is possibility that the file will NOT need to move, as it could actually be where is should be either because of size or because it already is in the disk it should be anyway. If DRUs are few (say three), the chances of this are quite large.

Just trying to help here.

Well there is a conflict of philosophy.

If you constantly write to the drive with the most space you end up having files (of a single folder) spread all over. There goes green (and speed and and...).
It's like WHS (and x-WHS users can tell you what the file system looks like after WHS "treats" it).

If you prefer to write to the drive that already hosts the closest path with the one you need, then you need to make sure what you are writing fits.

Brahim's idea of keeping a reserve number is good.
unRAID used another idea. A cache disk. Files get sent there and then invisibly scheduled they go were they should.
This whole thing is a matter Brahim has to give way more thought (one more thing in fact).

This is ALSO a matter of philosophical conflict. There are two schools: Give them all the options (for example even give me my damn implicit merge if I want it) and let them make the most appropriate config for their need, OR choose the best options I can implement (and think they are best anyway) and try to make this work as good as possibly for all cases (even for cases where another set of options could be better).
A first look would say that the first "school" is more difficult. Not so. Following the second school and making it smart enough is potentially more complex.

If Brahim's system internally is properly modular, he can push those decisions a bit further in time - else if the whole system is monolithic, he has to decide... now while in the beta!

With this I extend my invitation to Brahim to also check out other brains for ideas (not only for beta testing). FlexRAID 2.0 is a good start.

webs0r maybe since this thread is the only one actually talking about Live, should also have a copy of the details about autostart.txt and the fix you mention?

I understand why you did it like that (only writing through your system you can get notification to update the parity), but I hate that I can't skip using "view" (you know why, I am not re-opening this).

Can you at least implement support for a DRU (possibly name it something else?) to not be used for writing? So that I can use the smart idea of that guy creating the whole tree structure (as deep as it goes, possibly thousands of folders total) in ONE disk and then making virtual folders based on that and hide this thing in some folder possibly in PPU?
(like drescribed here
http://www.openegg.org/forums/posts/list/523.page
and esp. this post
http://www.openegg.org/forums/posts/list/20/523.page#5495
...which is great but has a problem. The first drive will need to have the WHOLE tree (problem if you want to access it directly - maybe for reading - where you will have to search the whole tree to find in which folders you have actual data). But something like that:

("Tree" is the volume or whatever that holds the "merge" folder tree, but not used for writing, or calculating parity or anything - which will allow for much smaller "merge" configurations)
and in fact like that you don't need tree definition entries like this:
because it is actually "implied".

In fact would be even greater if this was in fact initialized by the system (if the user chooses to use a "tree" entry), by automatically issuing a command like

(or in fact use code that does this as robocopy is not available in all Windows versions at least not by default)
...and re-issue the command every time the user tries to edit "storage pool merge". This doesn't conflict with anything, it will just be helpful for using the system in systems with pre-existing data, and then let FlexRAID handle things THROUGH the merged view from then on.

Whadaya think?

OK clear.

Tomorrow more tests.