From 54dfe9966c7d9c47fc4e38cf962b27ee7f8dda4a Mon Sep 17 00:00:00 2001
From: Dmitry Litvintsev <litvinse@fnal.gov>
Date: Wed, 8 Nov 2023 17:16:25 -0600
Subject: [PATCH] squash most of the typos
---
docs/cta_schema.rst | 6 +++---
docs/dcache_setup.rst | 4 ++--
docs/dcache_sfa.rst | 4 ++--
docs/enstore2cta_config.rst | 2 +-
docs/enstore2cta_script.rst | 10 +++++-----
docs/enstore_schema.rst | 14 +++++++-------
enstore2cta/scripts/enstore2cta.py | 2 +-
7 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/docs/cta_schema.rst b/docs/cta_schema.rst
index d074ed1..2011b07 100644
--- a/docs/cta_schema.rst
+++ b/docs/cta_schema.rst
@@ -8,7 +8,7 @@ Here is CTA schema:
Unlike Enstore schema, the CTA db schema is more normalized and specifically
separates out the concepts of logical libraries, virtual organization, storage class into corresponding tables. Therefore, the names of ``virtual_organization``, ``logical_library`` and ``storage_class`` have to be defined by admin in advance before any file can be written.
-Additonally CTA has a concept of ``tape_pool`` that represents logical grouping
+Additionally CTA has a concept of ``tape_pool`` that represents logical grouping
of tapes. Each tape belongs to exactly one tape pool. Tape pools are used to keep data belonging to different VOs, storage_class (via ``archive_route``).
The ``archive_route`` table connects ``storage_class`` to ``tape_pool`` and specifies how many copies a file must have.
@@ -19,9 +19,9 @@ File table
CTA separates the concept of `file` into an abstract ``archive_file`` that may
have multiple corresponding ``tape_file`` entries. The ``archive_file`` table stores file size; adler32 checksum; dis instance name; ``disk_file_id`` - an inode number on storage front end; unique file id (``archive_file_id``); user UID/GID and a deleted flag.
-A ``tape_file`` references ``archive_file`` and contains infromation that ties it to the tape - like volume id (``vid``); location on the tape and copy number.
+A ``tape_file`` references ``archive_file`` and contains information that ties it to the tape - like volume id (``vid``); location on the tape and copy number.
Storage class table
-------------------
-The storage class concept is somewhat similar to file family concept of Enstore. Besides unique name ``stotrage_class_name`` it specifies how many copes a file must have. And it has a reference to ``virtual_orhanization``.
+The storage class concept is somewhat similar to file family concept of Enstore. Besides unique name ``storage_class_name`` it specifies how many copes a file must have. And it has a reference to ``virtual_organization``.
diff --git a/docs/dcache_setup.rst b/docs/dcache_setup.rst
index d31b9ec..101e996 100644
--- a/docs/dcache_setup.rst
+++ b/docs/dcache_setup.rst
@@ -5,7 +5,7 @@ dCache setup with CTA
Pool
----
-Deploy dcache-cta driver on pool node::
+Deploy dCache-CTA driver on pool node::
wget https://download.dcache.org/nexus/repository/dcache-cta/dcache-cta-0.8.0-1.noarch.rpm
rpm -Uvh --force dcache-cta-0.8.0-1.noarch.rpm
@@ -15,7 +15,7 @@ Define hsm on pool::
hsm create cta cta dcache-cta -cta-user=adm -cta-group=eosusers -cta-instance-name=eosdev -cta-frontend-addr=ctahost:17017 -io-port=1094
-Each pool on the pool node has to havea dedicated port.
+Each pool on the pool node has to have dedicated port.
Define queue on pool::
diff --git a/docs/dcache_sfa.rst b/docs/dcache_sfa.rst
index f49688f..cee3b39 100644
--- a/docs/dcache_sfa.rst
+++ b/docs/dcache_sfa.rst
@@ -2,7 +2,7 @@ SFA files
=========
One of the issues that has been identified - CTA does not have
-functinality corresponding to Enstore SFA (Small File Aggregation).
+functionality corresponding to Enstore SFA (Small File Aggregation).
In the nutshell the SFA system is as extension of Enstore system that
manages intermediate disk storage on the side (intermediate between
dCache and Enstore). Depending on policies based on ``file_family``,
@@ -24,6 +24,6 @@ We need to translate::
-> dcache://dcache/?store=vo&group=file_family&bfid={child_pnfsid}:package_pnfsid
I.e. the child/package relation exists as location in ``t_locationinfo`` Chimera
-table. As long as these locations exist dCache can read thise files from CTA using an hsm script. T.e. SAPPHIRE system is not need for reading of SFA files.
+table. As long as these locations exist dCache can read these files from CTA using an hsm script. T.e. SAPPHIRE system is not need for reading of SFA files.
This can be populated out of band.
diff --git a/docs/enstore2cta_config.rst b/docs/enstore2cta_config.rst
index 147737f..df81a44 100644
--- a/docs/enstore2cta_config.rst
+++ b/docs/enstore2cta_config.rst
@@ -2,6 +2,6 @@
Configuration
--------------
-Script expects configuration file ``enstore2cta.yaml`` in the current directory or pointed to by environment variable ``MIGRATION_CONFIG``. The yaml file has to have "0600" permission bits and has to have the following parameters defned:
+Script expects configuration file ``enstore2cta.yaml`` in the current directory or pointed to by environment variable ``MIGRATION_CONFIG``. The yaml file has to have "0600" permission bits and has to have the following parameters defined:
.. literalinclude:: ../etc/enstore2cta.yaml
diff --git a/docs/enstore2cta_script.rst b/docs/enstore2cta_script.rst
index de4c5fe..3e6b05d 100644
--- a/docs/enstore2cta_script.rst
+++ b/docs/enstore2cta_script.rst
@@ -2,16 +2,16 @@ enstore2cta - Enstore to CTA migration script
=============================================
The script ``enstore2cta.py``, located in ``enstore2cta/scripts``, implements
-database migration from Enstore DB tro CTA DB. Both databases must be
+database migration from Enstore DB to CTA DB. Both databases must be
`PostgreSQL` databases. The script has various steering options (see below).
-It spawns multuiple processes, each process processing a unique Enstore volume.
+It spawns multiple processes, each process processing a unique Enstore volume.
Requirements
------------
-The scrit works both with python2 and python3 and requires ``psycopg2`` module be installed (using ``pip`` or ``yum install python-psycopg2``).
+The script works both with python2 and python3 and requires ``psycopg2`` module be installed (using ``pip`` or ``yum install python-psycopg2``).
Invocation
@@ -49,7 +49,7 @@ Look for example in ``enstore2cta/etc``. It must have "0600" permission (to prot
single volume to existing system using --add option
(default: None)
--cpu_count CPU_COUNT
- override cpu count - number of simulateously processed
+ override cpu count - number of simultaneously processed
labels (default: 8)
single volume to existing system using --add option
@@ -58,5 +58,5 @@ Look for example in ``enstore2cta/etc``. It must have "0600" permission (to prot
The script can work with individual label(s) passed as comma separated values to ``--label`` option. Or it can be invoked with ``--all`` switch to migrate all labels. The migration is done by label.
-Additionally, on an existing CTA systenm one can use
+Additionally, on an existing CTA system one can use
``--add`` option to add a volume also specifying its ``--storage_class`` (e.g. "cms.foo") and ``--vo`` (e.g. "cms").
diff --git a/docs/enstore_schema.rst b/docs/enstore_schema.rst
index eb9cb12..b185ccb 100644
--- a/docs/enstore_schema.rst
+++ b/docs/enstore_schema.rst
@@ -14,14 +14,14 @@ File table
----------
Each file copy in Enstore is uniquely identified by a BFID - bit file id,
-which is a string obtained by adding a three letter `brand` (which is the same for all files in a given Enstore instance), the Unix epoch, multiplied by 100000 and a counter which is reserved to resolve collisions. BFID is generated in the code base and is iserted into ``file`` table where it has unique contraint. If insert fails, the counter is incremented and the record insertion is tried again. And so on until it succeeds.
+which is a string obtained by adding a three letter `brand` (which is the same for all files in a given Enstore instance), the Unix epoch, multiplied by 100000 and a counter which is reserved to resolve collisions. BFID is generated in the code base and is inserted into ``file`` table where it has unique constraint. If insert fails, the counter is incremented and the record insertion is tried again. And so on until it succeeds.
.. code-block:: python
bfid = "CDMS" + str(time.time()*100000)
Each file record contains PNFSID (dCache inode identifier) that ties it back to
-the front end storage system; adler32 checksum; a reference to the file package for small files in SFA (Small File Aggregation) equal BFID of the package or ``null`` for `direct` files; file size; original file name; UID/GID of user who creted the file; tape location and a ``deleted`` flag that indicates whether or not the file
+the front end storage system; adler32 checksum; a reference to the file package for small files in SFA (Small File Aggregation) equal BFID of the package or ``null`` for `direct` files; file size; original file name; UID/GID of user who created the file; tape location and a ``deleted`` flag that indicates whether or not the file
has been removed from namespace.
Volume table
@@ -31,16 +31,16 @@ Every tape in Enstore is stored in the ``volume`` table.
The many to one ``file`` to ``volume`` relation is done on integer ``volume.id`` primary key via ``file.volume`` foreign key.
Each volume record tracks how many active/deleted/total files and bytes exist
-on the volume (via DB trigger on insert/update/delete). It has a volume label; total/remaining bytes; number of mounts; number of read and write accesses; severla status fields that allow to classify tapes (e.g. ``full``, ``NOACCESS``, ``NOTALLOWED``, ``migrated``, ``migrating``). The values of status fields are arbitrary strings.
+on the volume (via DB trigger on insert/update/delete). It has a volume label; total/remaining bytes; number of mounts; number of read and write accesses; several status fields that allow to classify tapes (e.g. ``full``, ``NOACCESS``, ``NOTALLOWED``, ``migrated``, ``migrating``). The values of status fields are arbitrary strings.
-The Enstore system has a concept of virtual library, so called libary manager (LM). The LM
+The Enstore system has a concept of virtual library, so called library manager (LM). The LM
manages a set of movers that have SCSI tape drives attached. LM (and movers) are Enstore servers and are configured based in Enstore instance configuration and are not captured in database schema. Each LM has a unique name and draws specific tapes allocated for it. This relation is captured in ``volume.library`` field.
-Since Enstroe LMs map to actual physical tape libraries, the volumes have to be pre-allocated to specific LMs.
+Since Enstore LMs map to actual physical tape libraries, the volumes have to be pre-allocated to specific LMs.
-Accounting and data steering aspects of Enstore operations use ``volume.storage_group`` field (usually corresponding to a VO name); ``volume.file_family`` a string field that tells enstore to use the same set of tapes to write data having this attribute. ``volume.file_family_width`` an integer taht specified how many tape deives can be used simultaneously to write data with speciric ``file_family``.
+Accounting and data steering aspects of Enstore operations use ``volume.storage_group`` field (usually corresponding to a VO name); ``volume.file_family`` a string field that tells Enstore to use the same set of tapes to write data having this attribute. ``volume.file_family_width`` an integer that specified how many tape drives can be used simultaneously to write data with specific ``file_family``.
-Enstore does not have pre-defined ``library``, ``storage_group`` and ``file_family`` concepts. When files are written to Enstore it receives the instruction fo what (``library``, ``file_family``, ``file_family_width``) to use from Enstore command line client ``encp``. When invoked, the ``encp`` client takes these parameters from directory tags of the destination directory or they can be passed as options to encp. File family value can be completelty arbitrary and user defined. Specifying random ``library`` string results in failure to write if Enstore does not actually have a running LM with matching name.
+Enstore does not have pre-defined ``library``, ``storage_group`` and ``file_family`` concepts. When files are written to Enstore it receives the instruction of what (``library``, ``file_family``, ``file_family_width``) to use from Enstore command line client ``encp``. When invoked, the ``encp`` client takes these parameters from directory tags of the destination directory or they can be passed as options to encp. File family value can be completely arbitrary and user defined. Specifying random ``library`` string results in failure to write if Enstore does not actually have a running LM with matching name.
File copies
-----------
diff --git a/enstore2cta/scripts/enstore2cta.py b/enstore2cta/scripts/enstore2cta.py
index 641dac7..2f0fb72 100644
--- a/enstore2cta/scripts/enstore2cta.py
+++ b/enstore2cta/scripts/enstore2cta.py
@@ -1197,7 +1197,7 @@ def main():
action = "store",
type = int,
default = multiprocessing.cpu_count(),
- help="override cpu count - number of simulateously processed labels")
+ help="override cpu count - number of simultaneously processed labels")
args = parser.parse_args()