Discussion:
DFS Structure help
(too old to reply)
Barkley Bees
2008-12-03 10:08:34 UTC
Permalink
I am setting up DFS (R2) right now with namespaces and replication. I think
I may be making a fundamental mistake though with the structure. I will only
be using it for user folders at this time so I:

- created my namespace server: Server_A
- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
Users folder


Everything is great up to this point as I can now see "\\domain\users". When
I go to the Namespaces folder on the DFS Management conosle and drill down
to \\domain\users I don't see anything in the "Namespace" tab on the right.
I can of course add folders from but the existing subfolders under "USERS"
don't appear here.

Have I made "USERS" the DFS Root in this case? Should I be instead be
structuring it so that "USERS" is a namespace folder? I'm a little lost
now..ugh! Thanks.
Marcin
2008-12-03 19:33:33 UTC
Permalink
Barkley,
DFS is commonly used to minimize number of drive mappings/providing a single
point of entry to mulitple network shares. If this is your longer term goal
(obviously this does not apply at this point), you might want to change your
approach (and create a generic top level namespace with Users as its
folder). Otherwise, you will need to create another namespace (which, btw.
is certainly a possibility) if you decide to add another set of shared
folders to your DFS hierarchy at some point in the future...

hth
Marcin
Post by Barkley Bees
I am setting up DFS (R2) right now with namespaces and replication. I think
I may be making a fundamental mistake though with the structure. I will
- created my namespace server: Server_A
- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
Users folder
Everything is great up to this point as I can now see "\\domain\users".
When I go to the Namespaces folder on the DFS Management conosle and drill
down to \\domain\users I don't see anything in the "Namespace" tab on the
right. I can of course add folders from but the existing subfolders under
"USERS" don't appear here.
Have I made "USERS" the DFS Root in this case? Should I be instead be
structuring it so that "USERS" is a namespace folder? I'm a little lost
now..ugh! Thanks.
DaveMills
2008-12-04 07:29:36 UTC
Permalink
What I have done is
a) Create a DFS root like you. I called mine Storage so I have \\domain\storage
b) Added various folders to storage e.g. Users, Public, Confidential
c) Added links in these above folders the point to the physical data location
via it \\server\share reference. e.g.
\\domain\storage\public ---> \\server\public$
For home folders I added another layer so I can have home folders on the
department own servers
\\domain\storage\users\legal ---> \\legalserver\users$
\\domain\storage\users\engineers ---> \\engineersserver\users$

No data is ever stored directly in the DFS folder only Links are put there.
Post by Barkley Bees
I am setting up DFS (R2) right now with namespaces and replication. I think
I may be making a fundamental mistake though with the structure. I will only
- created my namespace server: Server_A
- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
Users folder
Everything is great up to this point as I can now see "\\domain\users". When
I go to the Namespaces folder on the DFS Management conosle and drill down
to \\domain\users I don't see anything in the "Namespace" tab on the right.
I can of course add folders from but the existing subfolders under "USERS"
don't appear here.
Have I made "USERS" the DFS Root in this case? Should I be instead be
structuring it so that "USERS" is a namespace folder? I'm a little lost
now..ugh! Thanks.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
Barkley Bees
2008-12-04 09:41:12 UTC
Permalink
Thanks for the answers. As mentioned before, mine is setup as
\\domain\users\ with the user folders in that directory. When I create the
actual user folders via AD Users & Computers (multiselecting a batch of test
user accounts - home folder: \\domain\users\%username%) the folders are of
course created but I notice they do not appear in the DFS Management console
namespace tab. Of course I can create a folder on the Namespace tab and it
appears in the users directory but I am left to wonder what the difference
is between the two ways of creating folders?

If may ask, why did you create them as hidden shares ($)?

* that said, I am considering going with the route you suggested David
(\\domain\dfs\users or similar). Not sure what the 'best practice' would be
in this case though.
Post by DaveMills
What I have done is
a) Create a DFS root like you. I called mine Storage so I have
\\domain\storage
b) Added various folders to storage e.g. Users, Public, Confidential
c) Added links in these above folders the point to the physical data location
via it \\server\share reference. e.g.
\\domain\storage\public ---> \\server\public$
For home folders I added another layer so I can have home folders on the
department own servers
\\domain\storage\users\legal ---> \\legalserver\users$
\\domain\storage\users\engineers ---> \\engineersserver\users$
No data is ever stored directly in the DFS folder only Links are put there.
Post by Barkley Bees
I am setting up DFS (R2) right now with namespaces and replication. I think
I may be making a fundamental mistake though with the structure. I will only
- created my namespace server: Server_A
- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
Users folder
Everything is great up to this point as I can now see "\\domain\users". When
I go to the Namespaces folder on the DFS Management conosle and drill down
to \\domain\users I don't see anything in the "Namespace" tab on the right.
I can of course add folders from but the existing subfolders under "USERS"
don't appear here.
Have I made "USERS" the DFS Root in this case? Should I be instead be
structuring it so that "USERS" is a namespace folder? I'm a little lost
now..ugh! Thanks.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
DaveMills
2008-12-05 06:36:23 UTC
Permalink
Post by Barkley Bees
Thanks for the answers. As mentioned before, mine is setup as
\\domain\users\ with the user folders in that directory. When I create the
actual user folders via AD Users & Computers (multiselecting a batch of test
user accounts - home folder: \\domain\users\%username%) the folders are of
course created but I notice they do not appear in the DFS Management console
namespace tab. Of course I can create a folder on the Namespace tab and it
appears in the users directory but I am left to wonder what the difference
is between the two ways of creating folders?
I do not know why the folders do not display in the DFS Management console, I
have never tried to have non DFS managed folders within the DFS root.

In my opinion this is a poor design because you have no control over the
replication. All DFS root servers get a replicated copy of the content of the
DFS root and you cannot change that. This means that many GB of data will be
moved between the root servers when they synchronize. There is no interface for
managing the schedule or any other parameters. You may be able to via DFSUTIL or
registry changes but the system is not designed to be used in this way so I
would not be surprised to find a future update changing things in a way the will
break your system. You should change the design to have \\Domain\DFSRoot\Users
where Users is a link to a \\server\users($) share where the actual %username%
folders are stored. If you want replication of the Users folders then simply set
it up when you add a second link to another server share. This will be far more
flexible. You may have 2 replicated copies of the "Users" folder, no replication
on the "Public" link or any other combination you desire. The way you have
things will not allow you to expand the system for future needs, to change
target servers etc.

(A side note: Be careful with the NTFS permissions in the physical DFSRoot
folders, these are not replicated but inherited from the parent folder when the
root server is set up. I had one copy with Admin=F/C + Everyone=R and the other
as Everyone=F/C. It took me some time to figure out how people were able to add
files to the root because when I looked I saw the more restricted permission
set)


If you have not yet read "How DFS works" on
http://technet.microsoft.com/en-us/library/cc782417.aspx
You may find it very useful. I can't say I remember it all but it sure helped me
understand why I needed to be careful with the design.
Post by Barkley Bees
If may ask, why did you create them as hidden shares ($)?
So users will connect to the DFS paths and not the server UNC path (I know this
is not enforced). If users connect to the UNC name directly I loose to ability
to move the share to a new server and simply change the link in the DFS console
to point to the new location. Instead I have to get all clients to change their
configuration.
Post by Barkley Bees
* that said, I am considering going with the route you suggested David
(\\domain\dfs\users or similar). Not sure what the 'best practice' would be
in this case though.
Post by DaveMills
What I have done is
a) Create a DFS root like you. I called mine Storage so I have \\domain\storage
b) Added various folders to storage e.g. Users, Public, Confidential
c) Added links in these above folders the point to the physical data location
via it \\server\share reference. e.g.
\\domain\storage\public ---> \\server\public$
For home folders I added another layer so I can have home folders on the
department own servers
\\domain\storage\users\legal ---> \\legalserver\users$
\\domain\storage\users\engineers ---> \\engineersserver\users$
No data is ever stored directly in the DFS folder only Links are put there.
Post by Barkley Bees
I am setting up DFS (R2) right now with namespaces and replication. I think
I may be making a fundamental mistake though with the structure. I will only
- created my namespace server: Server_A
- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
Users folder
Everything is great up to this point as I can now see "\\domain\users". When
I go to the Namespaces folder on the DFS Management conosle and drill down
to \\domain\users I don't see anything in the "Namespace" tab on the right.
I can of course add folders from but the existing subfolders under "USERS"
don't appear here.
Have I made "USERS" the DFS Root in this case? Should I be instead be
structuring it so that "USERS" is a namespace folder? I'm a little lost
now..ugh! Thanks.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
Barkley Bees
2008-12-08 09:14:43 UTC
Permalink
1. Thanks for the advice, I have got my Namespace and Replication in place
as follows:

Server_A E:\Users$
Server_B E:\Users$

Namespace: \\domain\DFS\
Namespace folder: USERS

(I will be configuring the users' home path in AD as follows -
\\domain\dfs\users\%username%)

We are attempting to have Server_A be the main server with Server_B as a
"hot stand-by" so to speak. So, I have configured Server_A to be "first
among all targets" and Server_B to be "last among all targets in Namespaces.
I have done the same for the Folder "Users" in Namespaces. Does this appear
to be correct?

3. I have set up a replication group for these folders to sync. We will be
replicating ~2TB of data between severs. What would be the recommended quota
sizes for:

-Staging folder (4096MB default)
-Conflict and Deleted folder (660MB default)

4. To facilitate our "hot stand-by" goal, we would like to implement one-way
replication but I am beginning to wonder if there is any merit to this. I
had planned to simply disable (not delete) the replication connection from
Server_B -> Server_A to prevent it replicating back to the primary. The in
the event of a failure on the primary server I would enable this connection
after recovery so Server_B could replicate back to Server_A.

Can anyone advise on this, should I abandon 1-way replication?

5. How does VSS work with DFS? Do I simply enable VSS on both servers'
volumes that host the shared folder in the replication group and restore
from the active server when required? Or is the VSS restore done from the
\\domain\dfs\share ?


6. I have asked this before but didn't get a clear response, does anyone
know about SiS (single instance storage) and getting it to work correctly in
a DFS scenario? I am a little bit wary of enabling this service as I don't
know how it would be have with the Common store folder not being replicated
(and also how it would function with VSS).

7. Do most of you using DFS deploy the Client failback patch (kb898900)?

Appreciate any feedback as always. Thanks.
Post by DaveMills
Post by Barkley Bees
Thanks for the answers. As mentioned before, mine is setup as
\\domain\users\ with the user folders in that directory. When I create the
actual user folders via AD Users & Computers (multiselecting a batch of test
user accounts - home folder: \\domain\users\%username%) the folders are of
course created but I notice they do not appear in the DFS Management console
namespace tab. Of course I can create a folder on the Namespace tab and it
appears in the users directory but I am left to wonder what the difference
is between the two ways of creating folders?
I do not know why the folders do not display in the DFS Management console, I
have never tried to have non DFS managed folders within the DFS root.
In my opinion this is a poor design because you have no control over the
replication. All DFS root servers get a replicated copy of the content of the
DFS root and you cannot change that. This means that many GB of data will be
moved between the root servers when they synchronize. There is no interface for
managing the schedule or any other parameters. You may be able to via DFSUTIL or
registry changes but the system is not designed to be used in this way so I
would not be surprised to find a future update changing things in a way the will
break your system. You should change the design to have
\\Domain\DFSRoot\Users
where Users is a link to a \\server\users($) share where the actual %username%
folders are stored. If you want replication of the Users folders then simply set
it up when you add a second link to another server share. This will be far more
flexible. You may have 2 replicated copies of the "Users" folder, no replication
on the "Public" link or any other combination you desire. The way you have
things will not allow you to expand the system for future needs, to change
target servers etc.
(A side note: Be careful with the NTFS permissions in the physical DFSRoot
folders, these are not replicated but inherited from the parent folder when the
root server is set up. I had one copy with Admin=F/C + Everyone=R and the other
as Everyone=F/C. It took me some time to figure out how people were able to add
files to the root because when I looked I saw the more restricted permission
set)
If you have not yet read "How DFS works" on
http://technet.microsoft.com/en-us/library/cc782417.aspx
You may find it very useful. I can't say I remember it all but it sure helped me
understand why I needed to be careful with the design.
Post by Barkley Bees
If may ask, why did you create them as hidden shares ($)?
So users will connect to the DFS paths and not the server UNC path (I know this
is not enforced). If users connect to the UNC name directly I loose to ability
to move the share to a new server and simply change the link in the DFS console
to point to the new location. Instead I have to get all clients to change their
configuration.
Post by Barkley Bees
* that said, I am considering going with the route you suggested David
(\\domain\dfs\users or similar). Not sure what the 'best practice' would be
in this case though.
Post by DaveMills
What I have done is
a) Create a DFS root like you. I called mine Storage so I have \\domain\storage
b) Added various folders to storage e.g. Users, Public, Confidential
c) Added links in these above folders the point to the physical data location
via it \\server\share reference. e.g.
\\domain\storage\public ---> \\server\public$
For home folders I added another layer so I can have home folders on the
department own servers
\\domain\storage\users\legal ---> \\legalserver\users$
\\domain\storage\users\engineers ---> \\engineersserver\users$
No data is ever stored directly in the DFS folder only Links are put there.
Post by Barkley Bees
I am setting up DFS (R2) right now with namespaces and replication. I think
I may be making a fundamental mistake though with the structure. I will only
- created my namespace server: Server_A
- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
Users folder
Everything is great up to this point as I can now see "\\domain\users". When
I go to the Namespaces folder on the DFS Management conosle and drill down
to \\domain\users I don't see anything in the "Namespace" tab on the right.
I can of course add folders from but the existing subfolders under "USERS"
don't appear here.
Have I made "USERS" the DFS Root in this case? Should I be instead be
structuring it so that "USERS" is a namespace folder? I'm a little lost
now..ugh! Thanks.
--
Dave Mills
There are 10 types of people, those that understand binary and those
that
don't.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
DaveMills
2008-12-08 18:51:58 UTC
Permalink
Post by Barkley Bees
1. Thanks for the advice, I have got my Namespace and Replication in place
Server_A E:\Users$
Server_B E:\Users$
I assume you means E:\Folder shared as Server_X\Users$ in both cases.
Post by Barkley Bees
Namespace: \\domain\DFS\
Namespace folder: USERS
Created using the DFS Management console I assume.
Post by Barkley Bees
(I will be configuring the users' home path in AD as follows -
\\domain\dfs\users\%username%)
Fine
Post by Barkley Bees
We are attempting to have Server_A be the main server with Server_B as a
"hot stand-by" so to speak. So, I have configured Server_A to be "first
among all targets" and Server_B to be "last among all targets in Namespaces.
That is what I did but I often found Server_B was the active target even though
Server_A was operating normally.
Post by Barkley Bees
I have done the same for the Folder "Users" in Namespaces. Does this appear
to be correct?
You cannot configure the target for a folder in the root only a link or the DFS
root itself, unless I have missed something somewhere.
Post by Barkley Bees
3. I have set up a replication group for these folders to sync. We will be
replicating ~2TB of data between severs. What would be the recommended quota
Notice that the replication group will be replicating the physical folders not
via the shares. i.e. E:\Users$ on each server. I think you can even remove the
shares and DFS namespace and replication will continue (pointlessly)
Post by Barkley Bees
-Staging folder (4096MB default)
-Conflict and Deleted folder (660MB default)
I am not sure
Post by Barkley Bees
4. To facilitate our "hot stand-by" goal, we would like to implement one-way
replication but I am beginning to wonder if there is any merit to this. I
had planned to simply disable (not delete) the replication connection from
Server_B -> Server_A to prevent it replicating back to the primary. The in
the event of a failure on the primary server I would enable this connection
after recovery so Server_B could replicate back to Server_A.
Um, you will need to be absolutely certain that the clients cannot connect to
Server_B and as I noted above they sometimes will. This would mead actually
disabling the referrals to server B and manually enabling they in a failure.
This is what I am thinking of doing but not for several months.
Post by Barkley Bees
Can anyone advise on this, should I abandon 1-way replication?
5. How does VSS work with DFS? Do I simply enable VSS on both servers'
volumes that host the shared folder in the replication group and restore
from the active server when required? Or is the VSS restore done from the
\\domain\dfs\share ?
This was answered in another thread as the VSS runs independently on each
server. I have not looks and as yet do not have the resources to set up the
replication.
Post by Barkley Bees
6. I have asked this before but didn't get a clear response, does anyone
know about SiS (single instance storage) and getting it to work correctly in
a DFS scenario? I am a little bit wary of enabling this service as I don't
know how it would be have with the Common store folder not being replicated
(and also how it would function with VSS).
7. Do most of you using DFS deploy the Client failback patch (kb898900)?
Appreciate any feedback as always. Thanks.
Post by DaveMills
Post by Barkley Bees
Thanks for the answers. As mentioned before, mine is setup as
\\domain\users\ with the user folders in that directory. When I create the
actual user folders via AD Users & Computers (multiselecting a batch of test
user accounts - home folder: \\domain\users\%username%) the folders are of
course created but I notice they do not appear in the DFS Management console
namespace tab. Of course I can create a folder on the Namespace tab and it
appears in the users directory but I am left to wonder what the difference
is between the two ways of creating folders?
I do not know why the folders do not display in the DFS Management console, I
have never tried to have non DFS managed folders within the DFS root.
In my opinion this is a poor design because you have no control over the
replication. All DFS root servers get a replicated copy of the content of the
DFS root and you cannot change that. This means that many GB of data will be
moved between the root servers when they synchronize. There is no interface for
managing the schedule or any other parameters. You may be able to via DFSUTIL or
registry changes but the system is not designed to be used in this way so I
would not be surprised to find a future update changing things in a way the will
break your system. You should change the design to have
\\Domain\DFSRoot\Users
where Users is a link to a \\server\users($) share where the actual %username%
folders are stored. If you want replication of the Users folders then simply set
it up when you add a second link to another server share. This will be far more
flexible. You may have 2 replicated copies of the "Users" folder, no replication
on the "Public" link or any other combination you desire. The way you have
things will not allow you to expand the system for future needs, to change
target servers etc.
(A side note: Be careful with the NTFS permissions in the physical DFSRoot
folders, these are not replicated but inherited from the parent folder when the
root server is set up. I had one copy with Admin=F/C + Everyone=R and the other
as Everyone=F/C. It took me some time to figure out how people were able to add
files to the root because when I looked I saw the more restricted permission
set)
If you have not yet read "How DFS works" on
http://technet.microsoft.com/en-us/library/cc782417.aspx
You may find it very useful. I can't say I remember it all but it sure helped me
understand why I needed to be careful with the design.
Post by Barkley Bees
If may ask, why did you create them as hidden shares ($)?
So users will connect to the DFS paths and not the server UNC path (I know this
is not enforced). If users connect to the UNC name directly I loose to ability
to move the share to a new server and simply change the link in the DFS console
to point to the new location. Instead I have to get all clients to change their
configuration.
Post by Barkley Bees
* that said, I am considering going with the route you suggested David
(\\domain\dfs\users or similar). Not sure what the 'best practice' would be
in this case though.
Post by DaveMills
What I have done is
a) Create a DFS root like you. I called mine Storage so I have \\domain\storage
b) Added various folders to storage e.g. Users, Public, Confidential
c) Added links in these above folders the point to the physical data location
via it \\server\share reference. e.g.
\\domain\storage\public ---> \\server\public$
For home folders I added another layer so I can have home folders on the
department own servers
\\domain\storage\users\legal ---> \\legalserver\users$
\\domain\storage\users\engineers ---> \\engineersserver\users$
No data is ever stored directly in the DFS folder only Links are put there.
Post by Barkley Bees
I am setting up DFS (R2) right now with namespaces and replication. I think
I may be making a fundamental mistake though with the structure. I will only
- created my namespace server: Server_A
- Namespace name and settings: USERS (E:\DFSRoots\USERS\) <- Shared the
Users folder
Everything is great up to this point as I can now see "\\domain\users". When
I go to the Namespaces folder on the DFS Management conosle and drill down
to \\domain\users I don't see anything in the "Namespace" tab on the right.
I can of course add folders from but the existing subfolders under "USERS"
don't appear here.
Have I made "USERS" the DFS Root in this case? Should I be instead be
structuring it so that "USERS" is a namespace folder? I'm a little lost
now..ugh! Thanks.
--
Dave Mills
There are 10 types of people, those that understand binary and those
that
don't.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
Barkley Bees
2008-12-12 01:48:56 UTC
Permalink
Post by DaveMills
Post by Barkley Bees
3. I have set up a replication group for these folders to sync. We will be
replicating ~2TB of data between severs. What would be the recommended quota
Notice that the replication group will be replicating the physical folders not
via the shares. i.e. E:\Users$ on each server. I think you can even remove the
shares and DFS namespace and replication will continue (pointlessly)
Post by Barkley Bees
-Staging folder (4096MB default)
-Conflict and Deleted folder (660MB default)
I am not sure
Thanks for the advice DaveMills. Btw, I have found a good article on Staging
folder configuration which I will follow:

http://blogs.technet.com/filecab/archive/2006/03/20/422544.aspx

There are several factors that affect the size of staging. Without going
into theories, here are some rules of thumb:
1.. It is desirable to set the staging folder to be as large as possible
(as available space) and comparable to the size of the replicated folder.
Hence if the size of the replicated folder is 24.5 GB, then ideally a
staging folder of comparable size is desirable. Note that this amortizes the
cost of staging and hash calculation over all connections. It is also a best
practice to locate the staging folder on a different spindle to prevent disk
contention.
2.. If staging cannot be set comparable to the size of the replicated
folder, then reduce the size by 20%. Depending on how well the data
compresses, staging files will be 30-50% of the original file size.
3.. Note recommendations (1) and (2) are particularly important if all the
data is preexisting and DFS Replication must process all content at the same
time during initial replication. On the other hand, if the replicated folder
is relatively empty and gradually grows over time, the recommendation is to
determine the projected size of the replicated folder and size the staging
appropriately.
4.. If the size of the staging folder cannot be set proportional to the
size of the replicated folder, then increase the size of the staging folder
to be equal to the five largest files in the replicated folder.
5.. Also monitor for staging clean up events in the DFS Replication event
log (for example, event 4208 followed by 4206, which means that it was not
possible to stage a file due to lack of space and no further clean up was
possible), or frequent clean-up events (4202 followed by 4204). If more than
a few such event-pair occurs every hour, then increase the size of staging
by 50%.
DaveMills
2008-12-12 04:45:11 UTC
Permalink
Thanks, I have sent that to my hint and tip folder.
Post by Barkley Bees
Thanks for the advice DaveMills. Btw, I have found a good article on Staging
http://blogs.technet.com/filecab/archive/2006/03/20/422544.aspx
There are several factors that affect the size of staging. Without going
1.. It is desirable to set the staging folder to be as large as possible
(as available space) and comparable to the size of the replicated folder.
Hence if the size of the replicated folder is 24.5 GB, then ideally a
staging folder of comparable size is desirable. Note that this amortizes the
cost of staging and hash calculation over all connections. It is also a best
practice to locate the staging folder on a different spindle to prevent disk
contention.
2.. If staging cannot be set comparable to the size of the replicated
folder, then reduce the size by 20%. Depending on how well the data
compresses, staging files will be 30-50% of the original file size.
3.. Note recommendations (1) and (2) are particularly important if all the
data is preexisting and DFS Replication must process all content at the same
time during initial replication. On the other hand, if the replicated folder
is relatively empty and gradually grows over time, the recommendation is to
determine the projected size of the replicated folder and size the staging
appropriately.
4.. If the size of the staging folder cannot be set proportional to the
size of the replicated folder, then increase the size of the staging folder
to be equal to the five largest files in the replicated folder.
5.. Also monitor for staging clean up events in the DFS Replication event
log (for example, event 4208 followed by 4206, which means that it was not
possible to stage a file due to lack of space and no further clean up was
possible), or frequent clean-up events (4202 followed by 4204). If more than
a few such event-pair occurs every hour, then increase the size of staging
by 50%.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
Continue reading on narkive:
Loading...