Messages posted by: NLS

Make sure to leave a pointer/redirection.

No.

Although we are in the middle of Brahim changing the whole pooling backbone, I can attempt answering this.

1. Yes you can map. Certainly on top folder level. I am not sure deeper.

2. Like a normal mapped drive.

3. No keeps files whole.

4. Why not. It's a way to VIEW your data. In the next one even if it won't "migrate" you will just make it have the same configuration. I am not sure about the internal use of _flxrd_ folders though (which I hate btw...).

Yes because I use it in other places.

I can give you my openid and link to my page to check it out. If it gets you to the openid provider's login page, then it is ok.

OpenID delegation doesn't seem to work:

The database value you're trying to insert does not exist: server_url

(without delegation seems to work ok - I prefer to use my own domain though)

What about the old topics? Found a solution?

A good idea would be to add reporting in the web client for both, without making the user fiddle with debug levels.

Then don't add it in the pool.

Ah maybe, never noticed.

No.

No.

As for the config, personally I would make two DRU and one PPU. The PPU would be one of the 2TB, DRU1 would be the other 2TB and DRU2 would be the two 1TB disks together.

What is that blue icon on the virtual volume?
http://www.openegg.org/wp-content/uploads/2011/09/Full-Windows-Integration.png

Yes it will recognize the old settings.

But we cannot really talk about the future. Maybe Brahim will change something vital and make this incompatible. Refer to each future release notes.

You can normally use your original settings and metadata file and in that case won't have to rebuild anything.

I guess it depends from WHICH version you plan to update.

1. Agreed.

2. Maybe. Although the OS itself does quite a good job with this (call me MFT).

3. Erm... sounds weird and OS-or-3rd-party-app-unfriendly.

4. It's not a matter of printing anything. It is a matter of accessing (OS-friendly-way) the whole "merged" volume (up to accessing ACL, filesize and filetype details or so) without having to spin up all the disks.

How I see it is this. Recreate the MFT. I am not sure if you can use the already implemented OS functions to do it and actually "virtualize" where OS tries to store MFT information of the virtual volume - maybe in a file outside the array (in other words let the OS do most of the work), or you need to REBUILD some basic MFT-styled db. The first seems cleaner and more compatible if it can happen.

http://en.wikipedia.org/wiki/NTFS#Internals
http://www.easeus.com/data-recovery-ebook/ntfs-file-system-metafiles.htm

It shouldn't be to hard to implement since this function is already taken over by the virtual FS, but I am not sure of the extra recourses it would need.

We have to remember that not all people store blue-ray files in their arrays; other people (like me), might store millions of tiny files! (computer emulation is one case).

Nice. I probably have a few of those.

(even have my own openid site)

This would need the complete file metadata for EACH file, to be stored on one disk (along with pool metadata probably).

There should be a way to switch this off and there should be a mechanism to refresh it (even better, to be user selectable what to refresh... like "right mouse button/refresh metadata for this" (where "this" could be a file or a whole folder or of course whole volume).

Same here IF (Brahim is) interested.

Yes, no.