| |
|
|
|
| |
|
| Network Attached Storage (NAS) |
|
Backup operations have evolved in terms of both user requirements and the technology used to accomplish backups. Usage requirements have dictated that backups be made more frequently, yet without disrupting application access to data. Backup operations evolved from stand-alone backups to backup operations happening across a local area network (LAN or Lan) to backup operations happening in a network attached storage (NAS or Nas), also known as file sharing.
NAS uses hard disk drive storage that is set up with its own network address rather than being attached to the computer that is serving applications to a network's workstation users. By removing storage access and its management from the server, both application programming and files can be served faster because they are not competing for the same processor resources. The NAS device is attached to a LAN, typically, an Ethernet network, and assigned an IP (instruction pointer) address using protocols such as Microsoft's Internetwork Packet Exchange and NetBEUI, Novell's Netware Internetwork Packet Exchange, and Sun Microsystems' Network File System. File requests are mapped by the main server to the NAS file server. NAS consists of hard disk drive storage, including multi-disk RAID subsystems, and software for configuring and mapping file locations to the NAS device. NAS can be a step toward and included as part of a more sophisticated storage system called storage area network (SAN or San), also known as block sharing.
Moreover, the assignment of different categories of data to different types of storage media in order to reduce total storage cost, value or importance, can be implemented as part of a tiered (classed or levelled) storage system. Categories may be based on levels of protection needed, performance requirements, frequency of use, and other considerations, rather than managed uniformly. Tier 1(class A or level Platinum), data, e.g., mission-critical, recently accessed, or top secret files stored on expensive and high-quality media such as double-parity RAIDs; tier 2 (class B or level Gold) data, e.g., financial, seldom-used, or classified files stored on less expensive media in conventional storage area networks (SANs). As the tier number increases, cheaper media may be used. Therefore, tier 3 (class C or level Silver) in a 3-tier storage system might contain event-driven, rarely used, or unclassified files on recordable optical discs or tapes. Note: For completeness the final Tier is 4 (class D or level Bronze).
See: Storage Area Network (SAN). |
|
| |
|
| Ntbootdd.sys (Windows NT-based operating system system startup file #5) |
|
The device driver at the root of the system partition required for disk I/O SCSI or Advanced Technology Attachment [ATA] controllers with firmware disabled or which do not support extended INT-13 calls. The contents of this file depend on the startup controller used. Ntbootdd.sys is a copy of the miniport driver that Windows uses when it is fully operational to access the boot disk. The processor execution is in protected mode.
See: Device Drivers (location - systemroot\System32\Drivers - Windows NT-based operating system system startup file #9) |
|
| |
|
| Ntdetect.com (Windows NT-based operating system system startup file #4) |
|
The file at the root of the system partition that passes information about the hardware configuration to the NT Loader, Ntldr.exe. Ntoskrnl.exe is executed, passing the information returned by Ntdetect.com. The processor execution is in 16-bit real mode.
See: Ntldr (NT Loader; Windows NT-based operating system system startup file #1) |
|
| |
|
| NTFS (New Technology Filesystem) |
|
A native enterprise-class Windows filesystem format that uses 64-bit cluster numbers and advanced features: recoverability, performance, file and directory security (discretionary (need-to-know) access control), reliability, disk quotas, file compression, encryption, and directory-based symbolic links not found in any version of FAT, starts with a structure called a volume. A volume corresponds to a logical partition on a disk, and it is created when a disk or part of a disk is formatted for NTFS and regarded independent of any other volumes on the same disk or a separate disk altogether. For example, NTFS guarantees volume consistency by using standard transaction logging, recovery techniques, and object paradigms. It also supports object-oriented applications by treating all files as objects with user-defined and system-defined attributes.
If a system fails, e.g., system failure, power failure and so on, a recoverable filesystem such as NTFS is designed to reconstruct the disk volume structure. This capability means that I/O operations in progress at the time of a system failure must be either entirely completed or entirely backed up from the disk when the system is restarted – this is known as atomic transaction. Half-completed I/O operations (modifications or transactions to the database) can corrupt a disk volume and even render an entire volume available but inaccessible if the database is subsequently corrupted. To avoid this situation, a recoverable filesystem such as NTFS uses its log file using the log file service (LFS) to track changes in metadata (its integrity is guaranteed) in a transaction-processing scheme in which it records every volume update completely written to disk before the update itself is applied to the volume and it intends to make to the filesystem structure (the filesystem’s metadata (reference to changes in the filesystem and directory creation, renaming and deletion)) before it writes the change to the volume, and checkpoint information to restore the consistency of the filesystem. A system failure will not affect the correctness or integrity of the database. Consequently, filesystem structures can be repaired to a consistent state with no loss of file or directory structure information (file data can be lost as this is secondary) via the update records which is the most common type of record NTFS writes to its log, as each record contains the information required to redo an operation that updated the filesystem structure using a rollback feature. The rollback feature returns the database to a previously known and consistent state, as if the transactions had never taken place, is swift for even very large disks. For a recoverable filesystem such as NTFS to be successful disk writes are cached and the Cache Manager and the filesystem must work together. This interaction between filesystem and Cache Manager ensures the recoverability of the disk volume after a system failure. If the system fails, interrupting volume modifications in progress, the recoverable filesystem uses information stored in the log to reissue the volume updates. In addition to the recovery features mentioned, NTFS uses redundant storage for vital filesystem information so that if a sector on the hard disk drive goes bad, NTFS can still access the volume’s critical filesystem data. This redundancy of filesystem data contrasts with the on-disk structures of both the FAT filesystems. On FAT systems, if a read error occurs in one of these critical sectors an entire volume can be lost.
Unlike the FAT filesystem volume which contains areas specifically formatted for use by the filesystem, an NTFS volume stores all filesystem data, such as bitmaps and directories, and even the system bootstrap, as ordinary files. For this reason an NTFS volume is recommend to be less than 400MB because of the MFT over head.
As NTFS uses 64-bit cluster size numbers, this capacity gives NTFS the ability to address volumes of up to 16 exabytes (16EB). However, Windows limits the size of an NTFS volume to that addressable with 32-bit clusters, which is slightly less that 256TB (using 64-bit clusters). In addition, the NTFS format allows for files that are 16 exabytes in size, but the implementation limits the maximum file size to 2^64 16TB (16 EB or 18,446,744,073,709,551,616 bytes). Moreover, a major design feature of a Windows NT family operating system at every level is to provide a platform that can be use to be added to and built upon, and NTFS is no exception; providing a rich and flexible platform for other filesystems beside other advantages.
Both NTFS and FAT (Windows 9x onwards) allow each filename in a path (directory path) to contain as many as 255 (Windows 95 VFAT) and 260 (Windows NT family operating systems, NTFS) characters long. Filenames can contain Unicode characters as well as multiple periods ( . ) or separator and embedded spaces. 8.3 filenames are retained alone with long filenames; filenames preserve case, but are not case sensitive. There is no distinction of filenames based on case although certain characters are not permitted to use the control characters (? " / \ < > * | :). Using the command line filenames cannot exceed 253 characters.
For a primary partition with an NTFS it is represented within the partition table of the MBR as type/descriptor 07h 0r 0x07. An NTFS boot partition must be within the first 2GB.
See: Allocation Unit (or Cluster), Bad Block or Bad Sector, Bad Cluster, Cluster (or Allocation Unit), Dynamic Cluster Remapping, Exabyte (a million terabytes, symbol EB), FAT (12-, 16-, and 32-bit), Filename, File Reference Number, Log File, Logging, Master File Table (MFT), Metadata, Terabyte (symbol TB or Tb), and Volume. |
|
| |
|
| NTFS File Attribute |
|
Every allocated sector on a NTFS volume belongs to a file. Even the NTFS filesystem’s metadata is part of a file. NTFS views each file (or folder) as a set of file attributes. Elements such as the file name, its security information, and even its data, are all attributes. An attribute type code and, optionally, an attribute name identify each attribute. When a file’s attribute can fit within the Master File Table (MFT) file record for that file, they are called resident attributes. Information such as a file name and timestamp are always resident attributes. When the information for a file is too large to fit in its MFT file record, some of the file attributes are non-resident.
Non-resident attributes are allocated one or more clusters of disk space and are stored as an alternate data stream (ADS) in the volume.
See: Attribute (Resident & Non-Resident), Attribute list, B-tree, and Master File Table (MFT). |
|
| |
|
| Ntldr (NT Loader; Windows NT-based operating system system startup file #1) |
|
Ntldr.exe (NTLDR or NT Loader) is the boot loader for Windows NT family operating systems, including its later versions (2000/XP/Server 2003 but not Windows Vista, which divides the functionality of NTLDR between two new components: winload.exe and the Windows Boot Manager). Ntldr.exe requires, at a minimum, the following two files to be on the system volume: Ntldr.exe, which contains the main boot loader itself, and Boot.ini, which contains configuration options for a boot menu. To load a Windows NT family operating system, ntdetect.com must also be present. The Volume Boot Record (VBR) written to disc by the Windows NT format command attempts to load and run the NTLDR program.
The Windows NT family operating system’s loader file (ntlder.exe, NTLDR or NT Loader) at the root of the system partition that conducts the first portion of the Windows boot process. Ntldr resides on the system partition; the boot-sector code (executable code) on the system volume executes Ntldr. Ntldr reads the Boot.ini file from the system volume and presents the computer’s boot choices (boot-selection menu) to the user. The partition names that Boot.ini designates are in the form multi(0)disk(0)rdisk(0)partition(1). Ntldr translates the name of the Boot.ini boot entry and the user selects the appropriate boot partition and then loads the Windows NT family operating system (starting with the registry, Ntoskrnl.exe, Bootvid.dll (boot video driver), Hal.dll and the boot start device-drivers) into memory to continue the boot process and turns on paging. Without exception, Ntldr uses the computer’s firmware (ROM BIOS and/or Option ROMs) to read the hard disk drive containing the system volume. Sometimes Ntldr relies on functions in the disk miniport driver, SCSI (pronounced scuzzy) subsystem for example, to read from the boot volume’s disk. Note: The NT Loader knows nothing about LDM partitioning. The amount of work a digital computer can do in a clock cycle is dependent on the width of its register. If Windows is a 32-bit operating system then the processor execution is in 32-bit protected mode. If Windows is a 64-bit operating system then the processor execution is in 64-bit protected mode. A 32-bit computer can do twice as much work per clock cycle as an otherwise-identical 16-bit computer; a 64-bit computer can do twice as much again compared to a 32-bit computer.
The executable instructions - called the boot code, reads the root directory to locate and load Ntldr. The role therefore of the boot code, containing just enough information (read-only filesystem code), is to give Windows information about the structure and format of a volume and to read in the Ntldr file from the root directory of the volume. After the boot-sector code loads Ntldr into memory, it transfers control to Ntldr’s end point. If the boot sector cannot find Ntldr in the volume’s root directory, it displays error messages; for a FAT filesystem “”, for an NTFS filesystem “”
Ntldr begins its existence while a system is executing in an x86 operating mode called real mode. The first action of Ntldr is to switch from a 16-bit single-tasking to 32-bit multi-tasking (or protected mode) environment. Nevertheless, no virtual-to-physical translation occurs at this juncture in the boot process, but a full 32-bits of memory becomes available. Once the system is in protected mode, Ntldr is able to access the entire computer’s physical memory. After creating enough page tables to make memory below 16MB accessible with paging turned on, Ntldr enables paging. Protected mode with paging enabled is the mode in which Windows executes in normal operation. Once Ntldr enables paging it is fully operational. Nevertheless, Ntldr still relies on functions supplied by the boot code to access the IDE-based systems, boot a hard disk drive as well as the display. The boot code functions briefly, switching off paging and then switching the processor back to a mode in which services provided by the BIOS can be executed. If the hard disk drive containing the boot volume is SCSI-based and is not accessible using BIOS support, Ntldr loads a file called Ntbootdd.sys and uses it instead of the boot-code functions for disk access. Ntbootdd.sys is a copy of the miniport driver that Windows uses when it’s fully operational to access the boot hard disk drive (MBR disk). Ntldr then reads the Boot.ini file from the root directory using built-in system code. As with the boot sector’s code, Ntldr contains read-only NTFS and FAT code, unlike the boot sector’s code. However, Ntldr’s filesystem code can also read subdirectories.
The next stage for Ntldr is to clear the screen. If there is a valid Hiberfil.sys file in the root of the system volume it shortcuts the boot process by reading the contents of the file into memory and transferring control to code in the kernel that resumes a hibernated system. That code is represented for restarting drivers that were active when the system was shut down. Hiberfil.sys will be valid only if the last time the computer was shut down it was hibernated.
If there is more than one boot-selection entry in the Boot.ini, it presents the user with the boot-selection menu. If the boot-selection menus exceeds the timeout period specified by the Boot.ini file, or if there is only one entry, Ntldr bypasses the menu and continues with the default selection which is the top-most entry in Boot.ini with a path matching the path specified by the “default” line. Ntldr now executes Ntdetect.com to carry out some BIOS querying, Ntldr displays the “Startup Window” with the startup progress bar. This process bar remains empty until Ntldr begins loading boot drivers with the option to enter troubleshooting mode. For Windows XP/Server 2003, Ntldr simply presents the logo splash screen and no progress bar unlike for Windows 2000. Instead, the progress bar for Windows XP/Server 2003 moves from left-to-right repeatedly.
Selection entries in the Boot.ini direct Ntldr to the boot volume that corresponds to the partition on which the Windows system directory (by default, \Windows) of the selected installation resides. This partition may be the same as the boot partition, or it may be another primary partition.
If the Boot.ini entry refers to a DOS installation (that is, by referring to C:\ as that system partition), Ntldr reads the contents of the Bootsect.dos file into memory, switches back to 16-bit real mode, and calls the Master Boot Record (MBR) code in Bootsect.dos. This action causes the Bootsect.dos code to execute as if the MBR had read the code from disk. Code in Bootsect.dos continues a DOS-specific boot, such as is used to boot Windows 9x and Millennium, on a computer on which these operating systems are installed with Windows.
Entries in Boot.ini can include optional arguments that Ntldr and other components involved in the boot process will interpret.
Now Ntldr loads the appropriate kernel and HAL images (Ntoskrnl.exe and Hal.dll). If either of these important system files fails to load Ntldr will print the message “”, followed by the name of the file. Ntldr reads the SYSTEM registry hive, \Windows\System32\Config\System, so that it can determine which device drivers need to be loaded to accomplish the boot, scans the in-memory SYSTEM registry hive and locates all the boot device drivers that are necessary to boot the system, adds the filesystem driver that is responsible for implementing the code for the type of partition (FAT, FAT32, or NTFS) on which the installation directory resides, aforementioned, to the list of boot drivers to load, loads these boot drivers, which should only be drivers like the filesystem driver for the boot volume and so forth. While this is occurring Ntldr updates the progress bar as each driver is loaded (not initialised at this time). The final stage that Ntldr takes part in is to prepare the CPU registers for the execution of Ntoskrnl.exe and calls on Ntsokrnl.exe to perform the remaining system initialisation. As is evident, Ntldr is a very important system file.
The solution to “”, followed by the name of the file, is to read the detailed description pertaining to the RC herein. In addition to rebuilding the boot list, bootcfg will repair most “”, “”, “”, “”, “”, “”,or “”. The command process may apply to other types of Hive/system files/.exe/.dll related Stop Errors, Blue Screens, Stop Messages, Exception Errors, or Fatal System Errors.
Again from the RC, with respect to any system file, and using Hal.dll as the example, expand the file from the Windows CD-ROM, if necessary. The command would be expand d:\i386\hal.dl_ c:\windows\system32\hal.dll. Substitute d for the drive letter of the optical device.
Now use the command RC command “copy”, as follows (where d represents the location of your optical device).
First option:
C:\>COPY(space)C:\Windows\ServicePackFiles\System32\HAL.DLL(space)C:\Windows\System32\hal.dll
Second option:
C:\>COPY(space)d:\i386\hal.dl_(space)C:\Windows\System32\hal.dll
If the file to copy over means that an overwrite message appears, accept by depressing the “y” key. If the file to copy over is missing the file will just be copied.
Once the file has been expanded, if applicable, exit the RC and restart the computer.
Where the above procedure fails to fix the problem, follow the procedure below:
There are eight commands that need to be entered in sequence to repair any of the issues mentioned previously. These commands are as follows:
- CD.. (takes the command prompt one level up)
- ATTRIB –H C:\boot.ini
- ATTRIB –S C:\boot.ini
- ATRIB –R C:\boot.ini
- del boot.ini
- BOOTCFG /Rebuild
- CHKDSK /R /F
- FIXBOOT
- At the C:\> prompt, modify the attributes of the Boot.ini file using the following commands. This ensures that the Boot.ini file is no longer hidden, removes the flag that sets it as an undeletable system file, and removes the flag that sets it as a Read-only file and cannot be amended to.
- ATTRIB –H C:\ boot.ini
- ATTRIB –R C:\ boot.ini
- ATTRIB –S C:\boot.ini
- At the C:\> prompt delete the Boot.ini file using the following command:
- del boot.ini
- By booting into the RC and executing the bootcfg /rebuild command (Windows XP Recovery Console command), used to manipulate the Boot.ini file or add if one does not exist, it will invoke the RC to scan each volume looking for the WindowsNT/2000 and XP installation(s) when run from a Windows XP CD-ROM (clicking on Recovery Console), or installed locally from a Windows XP CD-ROM (selecting the command from the Boot menu) only. When the RC finds a Windows installation, it will ask the user whether it should add it to the Boot.ini file as a boot option and what name it should display for the installation in the boot menu. The one caveat being that due to file compatibility problems with an original Windows Setup CD-ROM it will not be possible to proceed further. For example, if the original or Windows Setup CD-ROM XP SP1 is use to carry out the repair, you will get a message that the upgrade is newer than the version to be extracted from the CD. To overcome this problem, the solution is the use a “slipstreamed” setup CD, which adds the newer files to the original Windows Setup CD. The slipstreamed (a constantly up-to-date) Windows Setup CD will simply fix all future installations and CD-based repairs. The command bootcfg/ list and then ENTER with present the contents of the Boot.ini file. It is possible to use the command line utility, Bootcfg.exe.
- Boot into the RC and executing the bootcfg /rebuild command as before, it will invoke the RC to scan each volume looking for the WindowsNT/2000 and XP installation(s). When the RC finds a Windows installation, it will ask the user whether it should add it to the Boot.ini file as a boot option and what name it should display for the installation in the Boot menu. Use a “slipstreamed” setup CD.
- You will be prompted with a message (the exact verbiage will depend on your setup) that states that the Total Identified Windows Installs: 1; [1] C:\Windows. Assuming that the information is correct, enter “y for Yes”. You may have to enter the Administrator account password; if the Administrator account password does not have one, press ENTER and Bootcfg will begin the process of rebuilding the boot list to include the indicated Windows installation.
You will be asked, “Enter Load Identifier”. This is the name of the operating system that will appear in the Boot menus. For consistency with the standard nomenclature used by Microsoft, enter “” or “”. Enter Operating System Load Options: (that is: /fastdetect, is a must; for Intel’s XD or AMD’s NX CPU buffer overflow protection, and for only these CPUs, also include /noexecute=option. See the screenshot above).
"
"
- Although not essential it may be prudent to include the following command:
- CHKDSK /R /F
- Where boot sectors of important filesystem’s critical structures that a computer uses to start up are located and may be suspected of being damaged, run the command fixboot (without any parameters). Executing the fixboot, command simplifies the boot process on multi-booting machines, removing non-essential boot variables, which in turn will help ensure that the repair of the operating system installation will have the best opportunity of carrying out a successful boot into Windows. Hit “y” to “Sure you want to write a new boot sector to the partition C:?”, then ENTER.
- Exit and leave the RC.
Side note: There are 80 boot device drivers each moving the progress bar 1.25 per cent of the way to completion – visible by the Windows progress bar (under Windows 2000). Windows places a limit on the size of the HKLM\SYSTEM hive because Ntldr reads this entire hive into physical memory near the start of the boot process, when virtual memory paging is not enabled, as a read-only hive. Ntldr also loads Ntoskrnl.exe and boot device drivers into physical memory, the amount of physical memory assigned to this hive must be limited. The upper limit that Ntldr places on HKLM\SYSTEM for Windows 2000 and Windows XP/Server 2003 is 12MB and 200MB respectively (or ¼ of physical memory, whichever is lower).
See: Active Partition, Boot.ini (non-Windows NT-based & Windows NT-based operating system system startup file #2), Boot Code, Boot Sector, Boot Partition, Bootstrap, Bootstrap Loader, Boot Volume, Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7), Ntbootdd.sys (Windows NT-based operating system system startup file #5), Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6), Real Mode, System Partition, System Volume, and Windows NT-Based Startup Phases.
Refer to the entry Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6) to follow the next phase in the system boot process and Windows NT-Based Startup Phases to see where Ntldr fits in. |
|
| |
|
| Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6) |
|
It is the executive (Windows executive) and kernel image of Windows NT family operating systems, providing the Executive layers of the windows NT kernel space, and is responsible for various system services used within executive components, i.e., Configuration Manager, Process & Thread Manager, Security Reference Monitor, I/O Manager, PnP Manager, Power Manager, WDM Windows Management Instrumentation routines, Cache Manager, Memory Manager and Logical Prefetcher, and kernel for uni-processor, for Windows NT family operating systems. Code that runs as part of the kernel does so in privileged processor mode with paging and has direct access to system data and hardware. During installation on single processor systems, Windows Setup copies Ntoskrnl.exe from the operating system CD-ROM. During installations on multi-processor systems, Windows Setup copies Ntoskrnlmp.exe and renames it Ntoskrnl.exe. Ntoskrnl.exe initialises executive subsystems, boot and system-start device drivers, prepares the system for running native applications, and runs Session Manager (smss.exe) using its functions RtlCreateUserThread and RtlCreateUserProcess. Smss is the only parentless process – the Son of the Kernel. Processor execution is protected mode with paging.
In more detail, the final stage that Ntldr takes part in is to prepare the CPU registers for the execution of Ntoskrnl.exe and calls on Ntsokrnl.exe to perform the remaining system initialisation. Ntldr passes a copy of the line in the Boot.ini that represents the boot selected menu option for the boot pointer to the memory table Ntldr generated to describe the physical memory on the system, a pointer to the in-memory copy of the HARWARE and SYSTEM registry hives, and a pointer to the list of point drivers Ntldr loaded.
It is now the turn of Ntoskrnl.exe to begin the first of two phases of the initialisation process. The first is called phase 0 and the second phase 1. Most executive subsystems have an initialisation function that takes the parameter that identifies which phase is executing. During phase 0, interrupts are disabled. The purpose of this phase is to build the basic structures necessary to allow the services needed in phase 1 to be summoned. During this phase the Hal function is called allowing it the opportunity to gain system control before Windows performs further significant initialisation. Next, initialisation routines are executed for the Memory Manager, Object Manager, Security Reference Monitor, Process Manager, and Plug and Play (PnP) Manager performing the following initialisation steps. Phase 1 completes 50 per cent of the start progress bar reported with the I/O Manager with intermediate steps of processes etc preceding it but not described here. The stage is a complex phase of system startup, first initialising various internal structures and then creating the driver and device object types. It then calls for the PnP Manager, Power Manager, and HAL to begin the various stages of dynamic device enumeration and initialisation and is a complex and specific process of the I/O system. The Windows Management Instrumentation (WMI) subsystem is initialised which provides WMI support for device drivers. Following on from this, all the boot-start drivers are called to perform their driver-specific initialisation, and the system-start device drivers are loaded and initialised etc. The Windows Start progress bar is now at 75 per cent. By 80 per cent paging in kernel-mode code (Ntoskrnl and driver) are enabled and the Power Manager begin initialising various power management structures. The final step is to create the Session Manager subsystem (smss.exe) process, which is responsible for creating the user-mode environment that provides the visible interface to Windows. The progress bar is now at 100 per cent.
Note: Windows provides several base mechanisms that kernel-mode components such as the Windows executive (upper layer of Nsokrnl.exe) use.
See: Device Drivers (location - systemroot\System32\Drivers - Windows NT-based operating system system startup file #9), Hal.dll (location - systemroot\System32 - Windows NT-based operating system system startup file #7), Windows Kernel (Lower Level Executive), Ntldr (NT Loader; Windows NT-based operating system system startup file #1), and Ntoskrnl.exe (location - systemroot\System32 - Windows NT-based operating system system startup file #6).
Refer to the entry Windows NT-Based Startup Phases to understand the remaining important processes and how they fit in with a normal and successful Windows startup. |
|
| |
|
| |
|
| |
|
|
