|
Home > Archive > Data Storage > February 2007 > ILM products (Kazeon) and Windows Explorer
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ILM products (Kazeon) and Windows Explorer
|
|
| byaarov@yahoo.com 2007-02-16, 7:12 pm |
| Hi,
How do ILM products like kazeon that migrate files to alternate
storage deal with Windows Explorer that do directory listings and try
to open each and every file to read the data (for thumbnails)?
Will this cause Kazeon to restore the files from alternate storage
back onto the primary disks?
Bargav
| |
| Nik Simpson 2007-02-17, 1:12 am |
| byaarov@yahoo.com wrote:
> Hi,
> How do ILM products like kazeon that migrate files to alternate
> storage deal with Windows Explorer that do directory listings and try
> to open each and every file to read the data (for thumbnails)?
>
> Will this cause Kazeon to restore the files from alternate storage
> back onto the primary disks?
>
They do any automatic migration back from the location when a file is
accessed, so it's a moot point.
--
Nik Simpson
| |
| Nik Simpson 2007-02-17, 7:12 am |
| Nik Simpson wrote:
> byaarov@yahoo.com wrote:
>
> They do any automatic migration back from the location when a file is
> accessed, so it's a moot point.
>
Of course, that should have read " they *DON'T* do any migration back
from a location"
--
Nik Simpson
| |
| Faeandar 2007-02-17, 7:12 pm |
| On 16 Feb 2007 11:40:09 -0800, byaarov@yahoo.com wrote:
>Hi,
>How do ILM products like kazeon that migrate files to alternate
>storage deal with Windows Explorer that do directory listings and try
>to open each and every file to read the data (for thumbnails)?
>
>Will this cause Kazeon to restore the files from alternate storage
>back onto the primary disks?
>
>Bargav
Lookup operations are not the same as access operations. Only access
ops cause an un-migration.
Also, there are no ILM "products". ILM is a process, if you don't
have that then you don't have ILM. You just have HSM.
~F
| |
| ron.lindman@gmail.com 2007-02-18, 7:13 pm |
| On Feb 17, 1:13 pm, Faeandar <mr_casta...@yahoo.com> wrote:
> On 16 Feb 2007 11:40:09 -0800, byaa...@yahoo.com wrote:
>
>
>
>
> Lookup operations are not the same as access operations. Only access
> ops cause an un-migration.
>
> Also, there are no ILM "products". ILM is a process, if you don't
> have that then you don't have ILM. You just have HSM.
>
> ~F
I think the OP is worried about exactly that. As far as I understand,
when Windows Explorer looks into a directory, it will often open and
read (ie. access) the files within so as to create thumbnails,
previews and the like. The question is, in spirit, similar to one I
posed a few weeks ago regarding full-text searches. I think what we're
all wondering is, given these application behaviors, how can migration
products really be both "automatic" and still provide the intended
benefit.
Thanks,
Ron
| |
| Faeandar 2007-02-18, 7:13 pm |
| On 18 Feb 2007 12:28:09 -0800, "ron.lindman@gmail.com"
<ron.lindman@gmail.com> wrote:
>On Feb 17, 1:13 pm, Faeandar <mr_casta...@yahoo.com> wrote:
>
>I think the OP is worried about exactly that. As far as I understand,
>when Windows Explorer looks into a directory, it will often open and
>read (ie. access) the files within so as to create thumbnails,
>previews and the like. The question is, in spirit, similar to one I
>posed a few weeks ago regarding full-text searches. I think what we're
>all wondering is, given these application behaviors, how can migration
>products really be both "automatic" and still provide the intended
>benefit.
>
>Thanks,
>Ron
Ouch. I can't speak to Windows behavior but that would be truly an
unhappy thing. I know these products have to take into account
possible scenarios like this so maybe it's only on write access or
open write access? I can't say.
I would be curious to know if someone finds out.
~F
| |
| byaarov@yahoo.com 2007-02-20, 1:13 pm |
| On Feb 18, 4:28 pm, Faeandar <mr_casta...@yahoo.com> wrote:
> On 18 Feb 2007 12:28:09 -0800, "ron.lind...@gmail.com"
>
>
>
> <ron.lind...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> Ouch. I can't speak to Windows behavior but that would be truly an
> unhappy thing. I know these products have to take into account
> possible scenarios like this so maybe it's only on write access or
> open write access? I can't say.
>
> I would be curious to know if someone finds out.
>
> ~F
Just got a response back from a neopath sales guy. They say their
product is the only one that handles this and prevents files from
being moved back onto primary just due to windows explorer directory
listings, but he didnt know how.
| |
| Nik Simpson 2007-02-23, 1:13 pm |
| byaarov@yahoo.com wrote:
>
> Just got a response back from a neopath sales guy. They say their
> product is the only one that handles this and prevents files from
> being moved back onto primary just due to windows explorer directory
> listings, but he didnt know how.
>
Salesguy, not a rocket scientist, film at 11 :-) Neopath is an inband
solution that provides a global namespace that sits in front of your NAS
devices. So any access to the filesystem (i.e. open, close, stat etc) is
actually a request to the Neopath appliance so it knows when a file is
opened and can presumably tell whether it's real access or just Explorer
doing it's thing.
The downsides with such a solution include:
Neopath has to be functioning for any access to occur
Neopath may become a performance bottleneck
Neopath only works with shared filesystems, if the filesystem you want
to manage is local to an application server or desktop, then it has to
be shared and made part of the Neopath global namespace and *ONLY*
accessed via Neopath.
So, you pays your money & you takes your choice. Solutions like Kazeon,
Scentric etc. our out-of-band. But as I've indicated in previous posts,
they don't any automatic backward migration of files once they've been
moved. You have to manually create policies that move the files back
based on your own criteria, for example you might leave the file in
place unless it has actually been modified as opposed to just looked at.
--
Nik Simpson
|
|
|
|
|