파일시스템
2011.03.17 13:41

EFS Internals

조회 수 112631 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

EFS Internals

EFS uses symmetric key encryption in combination with public key technology to protect files. File data is being encrypted with symmetric algorithm (DESX). The key, used in symmetric encryption is called File Encryption Key (FEK). The FEK in its own turn is encrypted with a public/private key algorithm (RSA) and stored along with the file. The reason why two different algorithms are used is the speed of encryption. The performance burden of asymmetric algorithms is too much to use them for encrypting a large amount of data. Symmetric algorithms are about 1000 times faster making their suitable for encrypting of large amounts of data.

As a first setp to encrypt file, NTFS creates a log file called Efs0.log in System Volume Information folder on the same drive, as encrypted file. Then EFS aquires access CryptoAPI context. It uses Microsoft Base Cryptographic Provider 1.0 as cryptographic provider. Having the crypto context open, EFS generate File Encryption Key (FEK).

The next step is to get public/private key pair; if it does not exist at this stage (the case when EFS invoked first time), EFS generate a new pair. EFS uses 1024-bit RSA algorithm to encrypt FEK.

Then, EFS creates Data Decryption Field (DDF) for the current user, where it places FEK and encrypts it with public key. If recovery agent is defined by system policy, EFS creates also Data Recovery Field (DRF) and places there FEK encrypted with public key of recover agent. A separate DRA is created for every recovery agent defined. Please note, that on Windows XP not included into domain, there's no recovery agent is defined, so this step is omitted.

Now a temporary file Efs0.tmp is created in the same folder as the file being encrypted. The contents of original file (plain text) is copied into temporary file, after that the original is overwritten with encrypted data. By default, EFS uses DESX algorithm with 128-bit key to encrypt file data, but Windows could be also configured to use stronger 3DES algorithm with 168-bit key. In that case FIPS compliant algorithms usage must be turned on in LSA policy (it is disabled by default):

EFS uses the registry to determine if it will use DESX or 3DES. If HKLMSYSTEMCurrentControlSetControlLSAFipsAlgorithmPolicy = 1, then 3DES will be used. If not, then EFS checks HKLMSoftwareMicrosoftWindows NTCurrentVersionEFSAlgorithmID (this value may not be present); if present, it will have ID CALG_3DES or CALG_DESX, otherwise, DESX should be used.

After encryption is done, temporary and log files are deleted.

 

After file is encrypted, only users who has correspondent DDF or DRF can access the file. This mechanism is separate from common security meaning that beside rights to access file, the file must have its FEK encrypted with user's public key. Only user who can decrypt FEK with his own private key, can access the file. The consequence is, that user, who has access to the file, can encrypt it thus preventing the owner to access his own file. Initially only one DDF is created for user who encrypts the file, but later he can add extra users to key ring. In this case EFS simply decrypts FEK with private key of user who wants to give access to the file to another user, and encrypts FEK with public key of target user, thus creating a new DDF which is stored along with the first one.

The decryption process is opposite to encryption:

First, system checks if user has a private key used by EFS. If yes, it reads EFS attributes and walk through the DDF ring looking for DDF for current user. If DDF is found, user's private key is used to decrypt FEK extracted from DDF. Using decrypted FEK, EFS decrypts file data. It should be noticed that file never decrypted in whole but rather by sectors when upper level module requests particular sector.

Recovery process is similar to decryption, except that it uses the recovery agent's private key to decrypt the FEK in the DRF, not in DDF:

DRA policy is implemented differently for Windows 2000 and Windows XP. In Windows 2000 by default on computers, not included into domain, local Administrator is added to Public Key Policy as Encrypted Data Recovery Agent. So, when user encrypts file, both DDF and DRF fields are created. If the last DRA is deleted, the whole EFS functionality is turned off and it is not possible to encrypt file anymore.

In Windows XP the situation is different. Since majority of home users working standalone do not need anybody else to be able to decrypt file except themselves, there's no need in data recovery agents, so there's no DRA included into Public Key Policy and EFS works without DRA. In this case only DDF field is created for encrypted file.

?

파일시스템
2011.03.17 13:40

Using EFS

조회 수 1557 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

Using EFS

User can invoke EFS features through Windows Explorer or by using a command-line utility called cipher.exe. To use Windows Explorer to encrypt file, open File property window by right clicking on file name. Click Advanced... button - Advanced Attributes dialog will be opened allowing you to mark file as encrypted.

Before saving new settings Windows will prompt user to encrypt file only or the whole folder. It address very important issue - while the file itself could be perfectly protected, the application which opens the file may create a temporary copies of the file while working with the document. The example is Microsoft Word. When user opens encrypted document, EFS decrypts it transparently for Word. Then during the work, Word creates temporary hidden file where it automatically saves the document in the process of editing and deletes it on the exit. This hidden file presents a real breach in security because it contains user data in plain (not encrypted) form. Encrypting the whole folder instead of file only solves this problem.

?

파일시스템
2011.03.17 13:40

EFS - Encrypting File System

조회 수 1560 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

EFS - Encrypting File System. Encrypted Files and Folders
(NTFS ver. 3.0 and newer)

The Encrypting File System (EFS) provides the core file encryption technology used to store encrypted files on NTFS volumes. EFS keeps files safe from intruders who might gain unauthorized physical access to sensitive, stored data (for example, by stealing a portable computer or external disk drive).

Users work with encrypted files and folders just as they do with any other files and folders. Encryption is transparent to the user who encrypted the file; the system automatically decrypts the file or folder when the user accesses. When the file is saved, encryption is reapplied. Users who are not authorized to access the encrypted files or folders transparently receive an "Access denied" message if they try to open, copy, move, or rename the encrypted file or folder. The exact message text may vary depending on application which tries to access the file, because it is related not to user rights for file but to ability of EFS to decrypt file using user's private key.

EFS has the following benefits over 3rd party encrypting applications:

  1. It is transparent for user and any applications. There's no risk for user to forget to encrypt file and leave data unprotected. Once file or folder is marked as encrypted, it will be encrypted in background without interaction with user. User does not need to remember password to decrypt files.
  2. Strong key security. In contrast to other solutions when keys are based on user entered pass-phrase, EFS generates keys which are tolerant to dictionary based attacks.
  3. All encrypting/decrypting processes are performed in kernel mode, excluding the risk of leaving key in paging file, from where it could be possibly extracted.
  4. EFS provides data recovery mechanism which is valuable in business environment, giving an organization an opportunity to restore data even if the employee who encrypted it left the company.
?

파일시스템
2011.03.17 13:39

NTFS Compressed Files

조회 수 1478 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

NTFS Compressed Files

Windows NT/2000 supports compression on individual files, folders, and entire NTFS volumes. Files compressed on an NTFS volume can be read and written by any Windows-based application without first being decompressed by another program.

Decompression occurs automatically when the file is read. The file is compressed again when it is closed or saved. Compressed files and folders have an attribute of C when viewed in Windows Explorer.

Only NTFS can read the compressed form of the data. When an application such as Microsoft® Word or an operating system command such as copy requests access to the file, the compression filter driver decompresses the file before making it available. For example, if you copy a compressed file from another Windows NT/2000-based computer to a compressed folder on your hard disk, the file is decompressed when read, copied, and then recompressed when saved.

NTFS allows for the compression of an entire volume, of one or more folders within a volume, or even one or more files within a folder of an NTFS volume.

The compression algorithms in NTFS are designed to support cluster sizes of up to 4 KB. When the cluster size is greater than 4 KB on an NTFS volume, none of the NTFS compression functions are available.

Each NTFS data stream contains information that indicates whether any part of the stream is compressed.

NTFS provides real-time access to a compressed file, decompressing the file when it is opened and compressing it when it is closed. When writing a compressed file, the system reserves disk space for the uncompressed size. The system gets back unused space as each individual compression buffer is compressed.

?

파일시스템
2011.03.17 13:38

NTFS Multiple Data Streams

조회 수 1387 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

NTFS Multiple Data Streams

NTFS supports multiple data streams, where the stream name identifies a new data attribute on the file. A handle can be opened to each data stream. A data stream, then, is a unique set of file attributes. Streams have separate opportunistic locks, file locks, and sizes, but common permissions.

This feature enables you to manage data as a single unit. The following is an example of an alternate stream:

myfile.dat:stream2	

A library of files might exist where the files are defined as alternate streams, as in the following example:

library:file1
:file2
:file3

A file can be associated with more than one application at a time, such as Microsoft® Word and Microsoft® WordPad. For instance, a file structure like the following illustrates file association, but not multiple files:

program:source_file
           :doc_file
           :object_file
           :executable_file

 

To create an alternate data stream, at the command prompt, you can type commands such as:

echo text>program:source_file
    more<program:source_file 

Important
When you copy an NTFS file to a FAT volume, such as a floppy disk, data streams and other attributes not supported by FAT are lost.

?

파일시스템
2011.03.17 13:37

NTFS 시스템 파일

조회 수 1558 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

NTFS System Files

NTFS includes several system files, all of which are hidden from view on the NTFS volume. A system file is one used by the file system to store its metadata and to implement the file system. System files are placed on the volume by the Format utility.

Table 5-4 Metadata Stored in the Master File Table

System File

File Name

MFT Record

Purpose of the File

Master file table

$Mft

0

Contains one base file record for each file and folder on an NTFS volume. If the allocation information for a file or folder is too large to fit within a single record, other file records are allocated as well.

Master file table 2

$MftMirr

1

A duplicate image of the first four records of the MFT. This file guarantees access to the MFT in case of a single-sector failure.

Log file

$LogFile

2

Contains a list of transaction steps used for NTFS recoverability. Log file size depends on the volume size and can be as large as 4 MB. It is used by Windows NT/2000 to restore consistency to NTFS after a system failure.

Volume

$Volume

3

Contains information about the volume, such as the volume label and the volume version.

Attribute definitions

$AttrDef

4

A table of attribute names, numbers, and descriptions.

Root file name index

$

5

The root folder.

Cluster bitmap

$Bitmap

6

A representation of the volume showing which clusters are in use.

Boot sector

$Boot

7

Includes the BPB used to mount the volume and additional bootstrap loader code used if the volume is bootable.

Bad cluster file

$BadClus

8

Contains bad clusters for the volume.

Security file

$Secure

9

Contains unique security descriptors for all files within a volume.

Upcase table

$Upcase

10

Converts lowercase characters to matching Unicode uppercase characters.

NTFS extension file

$Extend

11

Used for various optional extensions such as quotas, reparse point data, and object identifiers.

   

12-15

Reserved for future use.

Quota management file

$Quota

24

Contains user assigned quota limits on the volume space.

Object Id file

$ObjId

25

Contains file object IDs.

Reparse point file

$Reparse

26

This file contains information about files and folders on the volume include reparse point data

 

?

파일시스템
2011.03.17 13:36

NTFS 파일속성

조회 수 1311 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

NTFS File Attributes

The NTFS file system views each file (or folder) as a set of file attributes. Elements such as the file's name, its security information, and even its data, are all file attributes. Each attribute is identified by an attribute type code and, optionally, an attribute name.

When a file's attributes can fit within the MFT file record, they are called resident attributes. For example, information such as filename and time stamp are always included in the MFT file record. When all of the information for a file is too large to fit in the MFT file record, some of its attributes are nonresident. The nonresident attributes are allocated one or more clusters of disk space elsewhere in the volume. If all attributes can not fit into one MFT record NTFS creates additional MFST records and puts the Attribute List attribute to the first file's MFT record to describe the location of all of the attribute records.

Table 5-3 lists all of the file attributes currently defined by the NTFS file system. This list is extensible, meaning that other file attributes can be defined in the future.

Table 5-3 File Attributes Defined by NTFS

Attribute Type

Description

Standard Information

Includes information such as timestamp and link count.

Attribute List

Lists the location of all attribute records that do not fit in the MFT record.

File Name

A repeatable attribute for both long and short file names. The long name of the file can be up to 255 Unicode characters. The short name is the 8.3, case-insensitive name for the file. Additional names, or hard links, required by POSIX can be included as additional file name attributes.

Security Descriptor

Describes who owns the file and who can access it.

Data

Contains file data. NTFS allows multiple data attributes per file. Each file typically has one unnamed data attribute. A file can also have one or more named data attributes, each using a particular syntax.

Object ID

A volume-unique file identifier. Used by the distributed link tracking service. Not all files have object identifiers.

Logged Utility Stream

Similar to a data stream, but operations are logged to the NTFS log file just like NTFS metadata changes. This is used by EFS.

Reparse Point

Used for volume mount points. They are also used by Installable File System (IFS) filter drivers to mark certain files as special to that driver.

Index Root

Used to implement folders and other indexes.

Index Allocation

Used to implement folders and other indexes.

Bitmap

Used to implement folders and other indexes.

Volume Information

Used only in the $Volume system file. Contains the volume version.

Volume Name

Used only in the $Volume system file. Contains the volume label.

 

?

파일시스템
2011.03.17 13:35

NTFS MFT 분석

조회 수 1432 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

NTFS Master File Table (MFT)

Each file on an NTFS volume is represented by a record in a special file called the master file table (MFT). NTFS reserves the first 16 records of the table for special information. The first record of this table describes the master file table itself, followed by a MFT mirror record. If the first MFT record is corrupted, NTFS reads the second record to find the MFT mirror file, whose first record is identical to the first record of the MFT. The locations of the data segments for both the MFT and MFT mirror file are recorded in the boot sector.

Full list of metadata files are presented in the "System Files" chapter.

Figure provides a simplified illustration of the MFT structure:

Figure 5-2 MFT Structure

The master file table allocates a certain amount of space for each file record. The attributes of a file are written to the allocated space in the MFT. Small files and directories (typically 512 bytes or smaller), such as the file illustrated in next figure, can entirely be contained within the master file table record.

Figure 5-2 MFT Record for a Small File or Directory:

This design makes file access very fast. Consider, for example, the FAT file system, which uses a file allocation table to list the names and addresses of each file. FAT directory entries contain an index into the file allocation table. When you want to view a file, FAT first reads the file allocation table and assures that it exists. Then FAT retrieves the file by searching the chain of allocation units assigned to the file. With NTFS, as soon as you look up the file, it's there for you to use.

Directory records are housed within the master file table just like file records. Instead of data, directories contain index information. Small directory records reside entirely within the MFT structure. Large directories are organized into B-trees, having records with pointers to external clusters containing directory entries that could not be contained within the MFT structure.

?

파일시스템
2011.03.17 13:34

NTFS 파티션 부트섹터

조회 수 2070 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

Partition Boot Sector

Figure 5-1 Formatted NTFS Volume

 

Table 5-1 describes the boot sector of a volume formatted with NTFS. When you format an NTFS volume, the format program allocates the first 16 sectors for the $Boot metadata file. First sector, in fact, is a boot sector with a "bootstrap" code and the following 15 sectors are the boot sector's IPL (initial program loader). To increase file system reliability the very last sector an NTFS partition contains a spare copy of the boot sector.

Table 5-1 NTFS Boot Sector

Byte Offset

Field Length

Field Name

0x00

3 bytes

Jump Instruction

0x03

LONGLONG

OEM ID

0x0B

25 bytes

BPB

0x24

48 bytes

Extended BPB

0x54

426 bytes

Bootstrap Code

0x01FE

WORD

End of Sector Marker

On NTFS volumes, the data fields that follow the BPB form an extended BPB. The data in these fields enables Ntldr (NT loader program) to find the master file table (MFT) during startup. On NTFS volumes, the MFT is not located in a predefined sector, as on FAT16 and FAT32 volumes. For this reason, the MFT can be moved if there is a bad sector in its normal location. However, if the data is corrupted, the MFT cannot be located, and Windows NT/2000 assumes that the volume has not been formatted.

The following example illustrates the boot sector of an NTFS volume formatted while running Windows 2000. The printout is formatted in three sections:

  • Bytes 0x00- 0x0A are the jump instruction and the OEM ID (shown in bold print).
  • Bytes 0x0B-0x53 are the BPB and the extended BPB.
  • The remaining code is the bootstrap code and the end of sector marker (shown in bold print).
Physical Sector:Cyl 0, Side 1, Sector 1 
      00000000:EB 52 90 4E 54 46 53 20 -20 20 20 00 02 08 00 00 .R.NTFS ........ 
      00000010:00 00 00 00 00 F8 00 00 -3F 00 FF 00 3F 00 00 00 ........?...?... 
      00000020:00 00 00 00 80 00 80 00 -4A F5 7F 00 00 00 00 00 ........J....... 
      00000030:04 00 00 00 00 00 00 00 -54 FF 07 00 00 00 00 00 ........T....... 
      00000040:F6 00 00 00 01 00 00 00 -14 A5 1B 74 C9 1B 74 1C ...........t..t. 
      00000050:00 00 00 00 FA 33 C0 8E -D0 BC 00 7C FB B8 C0 07 .....3.....|.... 
      00000060:8E D8 E8 16 00 B8 00 0D -8E C0 33 DB C6 06 0E 00 ..........3..... 
      00000070:10 E8 53 00 68 00 0D 68 -6A 02 CB 8A 16 24 00 B4 ..S.h..hj....$.. 
      00000080:08 CD 13 73 05 B9 FF FF -8A F1 66 0F B6 C6 40 66 ...s......f...@f 
      00000090:0F B6 D1 80 E2 3F F7 E2 -86 CD C0 ED 06 41 66 0F .....?.......Af. 
      000000A0:B7 C9 66 F7 E1 66 A3 20 -00 C3 B4 41 BB AA 55 8A ..f..f....A..U. 
      000000B0:16 24 00 CD 13 72 0F 81 -FB 55 AA 75 09 F6 C1 01 .$...r...U.u.... 
      000000C0:74 04 FE 06 14 00 C3 66 -60 1E 06 66 A1 10 00 66 t......f`..f...f 
      000000D0:03 06 1C 00 66 3B 06 20 -00 0F 82 3A 00 1E 66 6A ....f;....:..fj 
      000000E0:00 66 50 06 53 66 68 10 -00 01 00 80 3E 14 00 00 .fP.Sfh.....>... 
      000000F0:0F 85 0C 00 E8 B3 FF 80 -3E 14 00 00 0F 84 61 00 ........>.....a. 
      00000100:B4 42 8A 16 24 00 16 1F -8B F4 CD 13 66 58 5B 07 .B..$......fX [.. 
      00000110:66 58 66 58 1F EB 2D 66 -33 D2 66 0F B7 0E 18 00 fXfX.-f3.f...... 
      00000120:66 F7 F1 FE C2 8A CA 66 -8B D0 66 C1 EA 10 F7 36 f......f..f....6
      00000130:1A 00 86 D6 8A 16 24 00 -8A E8 C0 E4 06 0A CC B8 ......$......... 
      00000140:01 02 CD 13 0F 82 19 00 -8C C0 05 20 00 8E C0 66 ..............f 
      00000150:FF 06 10 00 FF 0E 0E 00 -0F 85 6F FF 07 1F 66 61 ..........o...fa 
      00000160:C3 A0 F8 01 E8 09 00 A0 -FB 01 E8 03 00 FB EB FE ................ 
      00000170:B4 01 8B F0 AC 3C 00 74 -09 B4 0E BB 07 00 CD 10 .....<.t........ 
      00000180:EB F2 C3 0D 0A 41 20 64 -69 73 6B 20 72 65 61 64 .....A disk read 
      00000190:20 65 72 72 6F 72 20 6F -63 63 75 72 72 65 64 00 error occurred. 
      000001A0:0D 0A 4E 54 4C 44 52 20 -69 73 20 6D 69 73 73 69 ..NTLDR is missi 
      000001B0:6E 67 00 0D 0A 4E 54 4C -44 52 20 69 73 20 63 6F ng...NTLDR is co 
      000001C0:6D 70 72 65 73 73 65 64 -00 0D 0A 50 72 65 73 73 mpressed...Press 
      000001D0:20 43 74 72 6C 2B 41 6C -74 2B 44 65 6C 20 74 6F Ctrl+Alt+Del to 
      000001E0:20 72 65 73 74 61 72 74 -0D 0A 00 00 00 00 00 00 restart........
      000001F0:00 00 00 00 00 00 00 00 -83 A0 B3 C9 00 00 55 AA ..............U. 

The following table describes the fields in the BPB and the extended BPB on NTFS volumes. The fields starting at 0x0B, 0x0D, 0x15, 0x18, 0x1A, and 0x1C match those on FAT16 and FAT32 volumes. The sample values correspond to the data in this example.

Byte Offset

Field Length

Sample Value

Field Name

0x0B

WORD

0x0002

Bytes Per Sector

0x0D

BYTE

0x08

Sectors Per Cluster

0x0E

WORD

0x0000

Reserved Sectors

0x10

3 BYTES

0x000000

always 0

0x13

WORD

0x0000

not used by NTFS

0x15

BYTE

0xF8

Media Descriptor

0x16

WORD

0x0000

always 0

0x18

WORD

0x3F00

Sectors Per Track

0x1A

WORD

0xFF00

Number Of Heads

0x1C

DWORD

0x3F000000

Hidden Sectors

0x20

DWORD

0x00000000

not used by NTFS

0x24

DWORD

0x80008000

not used by NTFS

0x28

LONGLONG

0x4AF57F0000000000

Total Sectors

0x30

LONGLONG

0x0400000000000000

Logical Cluster Number for the file $MFT

0x38

LONGLONG

0x54FF070000000000

Logical Cluster Number for the file $MFTMirr

0x40

DWORD

0xF6000000

Clusters Per File Record Segment

0x44

DWORD

0x01000000

Clusters Per Index Block

0x48

LONGLONG

0x14A51B74C91B741C

Volume Serial Number

0x50

DWORD

0x00000000

Checksum

Protecting the Boot Sector

Because a normally functioning system relies on the boot sector to access a volume, it is highly recommended that you run disk scanning tools such as Chkdsk regularly, as well as back up all of your data files to protect against data loss if you lose access to a volume.

?

파일시스템
2011.03.17 13:31

NTFS 기초

조회 수 1083 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

NTFS 파일시스템은 FAT파일시스템에 비해 보다 나은 퍼포먼스, 신뢰성, 및 호환성을 제공합니다.

NTFS 파일시스템은 빠른 검색, 읽기, 쓰기을 제공하기 위해 설계된 파일시스템입니다. 또한 대용량 하드디스크에 대한 파일시세틈 복구기능을 제공합니다.

NTFS 파일시스템으로 포맷하는 경우 여러 메타데이타파일(MFT - Master File Table, $Bitmap, $LogFile )들이 생성됩니다. 이러한 메타데이타파일은 NTFS 볼륨의 파일이나 폴더들에 대한 정보가 저장됩니다.

The first information on an NTFS 볼륨의 첫번째 정보는 파티션 부트섹터 ($Boot metadata file) 입니다.

파티션 부트섹터는 sector 0 에 위치하며 16 sectors 의 크기로 확장될수 있습니다.

부트섹터는 기본 NTFS 볼륨정보 및 $MFT의 위치 정보가 저장됩니다.

 

다음은 디스크를 NTFS 볼륨으로 포맷했을 때 레이아웃입니다.

 

※ 포맷된 NTFS 볼륨

?

서버/레이드
2011.03.17 11:36

레이드란?

조회 수 1075 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

◆RAID (redundant array of independent [또는 inexpensive] disks)

 

RAID[레이드]는 중요한 데이터를 가지고 있는 서버에 주로 사용되며, 여러 대의 하드디스크가 있을 때 동일한 데이터를 다른 위치에 중복해서 저장하는 방법이다. 데이터를 여러 대의 디스크에 저장함에 따라 입출력 작업이 균형을 이루며 겹치게 되어 전체적인 성능이 개선된다. 여러 대의 디스크는 MTBF를 증가시키기 때문에 데이터를 중복해서 저장하면 고장에 대비하는 능력도 향상된다.

하나의 RAID는 운영체계에게 논리적으로는 하나의 하드디스크로 인식된다. RAID는 스트라이핑 기술을 채용하여 각 드라이브의 저장공간을 1 섹터(512 바이트)의 크기에서부터 수 MB에 이르는 공간까지 다양한 범위로 파티션할 수 있다. 모든 디스크의 스트라이프는 인터리브되어 있으며, 차례대로 어드레싱된다.

의료 및 기타 과학분야의 사진 등 대형 레코드가 저장된 단일 사용자용 시스템에서, 스트라이프는 으레 512 바이트 정도의 적은 량으로 설정되는데, 이를 통하여 하나의 레코드가 모든 디스크들에 걸쳐있게 되고, 또 모든 디스크를 동시에 읽음으로써 빠르게 접근할 수 있게된다.

다중 사용자시스템에서는 최대크기의 레코드를 넣을 수 있을 정도로 충분히 넓은 스트라이프를 확보함으로써 더 나은 성능을 발휘하게 되는데, 이는 드라이브간의 디스크 입출력을 중첩시켜준다.

RAID에는 중복되지 않는 어레이인 RAID-0를 제외하더라도, 9가지 형태가 더 있다.
 

  • RAID-0 : 이 방식은 스트라이프를 가지고는 있지만 데이터를 중복해서 기록하지 않는다. 따라서, 가장 높은 성능을 기대할 수 있지만, 고장대비 능력이 전혀 없으므로 이 방식은 진정한 RAID라고 하기 어렵다.
  • RAID-1 : 이 형식은 흔히 디스크 미러링이라고도 하는데, 중복 저장된 데이터를 가진 적어도 두 개의 드라이브로 구성된다. 스트라이프는 없으며, 각 드라이브를 동시에 읽을 수 있으므로 읽기 성능은 향상된다. 쓰기 성능은 단일 디스크 드라이브의 경우와 정확히 같다. RAID-1은 다중 사용자 시스템에서 최고의 성능과 최고의 고장대비 능력을 발휘한다.
  • RAID-2 : 이 형식은 디스크들간에 스트라이프를 사용하며, 몇몇 디스크들은 에러를 감지하고 수정하는데 사용되는 ECC 정보가 저장되어 있다. 이 방식은 RAID-3에 비해 장점이 없다.
  • RAID-3 : 이 형식은 스트라이프를 사용하며, 패리티 정보를 저장하기 위해 별도의 드라이브 한 개를 쓴다. 내장된 ECC 정보가 에러를 감지하는데 사용된다. 데이터 복구는 다른 드라이브에 기록된 정보의 XOR를 계산하여 수행된다. 입출력 작업이 동시에 모든 드라이브에 대해 이루어지므로, RAID-3은 입출력을 겹치게 할 수 없다. 이런 이유로 RAID-3는 대형 레코드가 많이 사용되는 업무에서 단일 사용자시스템에 적합하다.
  • RAID-4 : 이 형식은 대형 스트라이프를 사용하며, 이는 사용자가 어떤 단일 드라이브로부터라도 레코드를 읽을 수 있다는 것을 의미한다. 이것은 데이터를 읽을 때 중첩 입출력의 장점을 취할 수 있도록 한다. 모든 쓰기 작업은 패리티 드라이브를 갱신해야하므로, 입출력의 중첩은 불가능하다. RAID-4는 RAID-5에 비해 장점이 없다.
  • RAID-5 : 이 형식은 회전식 패리티 어레이를 포함한다. 그러므로 RAID-4에서의 쓰기 제한을 주소 지정한다. 그러므로 모든 읽기/쓰기 동작은 중첩될 수 있다. RAID-5는 패리티 정보를 저장하지만 데이터를 중복저장하지는 않는다 (그러나 패리티 정보는 데이터를 재구성하는데 사용될 수 있다). RAID-5는 보통 3 ~ 5개의 디스크를 어레이로 요구한다. RAID-5는 성능이 그리 중요하지 않고 쓰기 작업이 많지 않은 다중 사용자시스템에 적합하다.
  • RAID-6 : 이 형식은 RAID-5와 비슷하지만, 다른 드라이브들 간에 분포되어 있는 2차 패리티 구성을 포함함으로써 매우 높은 고장대비 능력을 제공한다. 현재로서는 RAID-6의 상용 모델은 거의 없다.
  • RAID-7 : 이 형식은 컨트롤러로서 내장되어 있는 실시간 운영체계를 사용하며, 속도가 빠른 버스를 통한 캐시, 독자적인 컴퓨터의 여러 가지 특성들을 포함하고 있다. 현재 단 하나의 업체만이 이 시스템을 제공한다.
  • RAID-10 : 이 형식은 각 스트라이프는 RAID-1 드라이브 어레이인 스트라이프 어레이를 제공한다. 이 방식은 RAID-1보다 높은 성능을 제공하지만, 값이 더 비싸다.
  • RAID-53 : 이 형식은 각 스트라이프는 RAID-3 디스크 에레이인 스트라이프 어레이를 제공한다. 이 방식은 RAID-3보다 높은 성능을 제공하지만, 값이 더 비싸다.
?

매킨토시
2011.03.17 10:08

맥사용시 주요장애원인과 대처

조회 수 1530 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

1. 맥 사용시 주로 나타나는 증상은

  • 맥 디스크 유틸리티의 잘못 사용으로 인한 볼륨손상
  • 맥 시스템에 연결된 디스크를 실수로 파티셔닝
  • 바이러스, 응용프로그램의 오류, 파워공급 문제로 인한 볼륨손상
  • 디스크의 배드섹터로 인한 폴더 접근장애
  • 디스크의 물리적인 인식불가 상태 등입니다.

 2. 주의사항

  • 맥시스템은 구조상 디스크 분리가 용이하지 않은 관계로 디스크 분리시에는 반드시 전문가에게 의뢰
  • 사용자의 실수에 의한 경우외에 디스크에 물리적인 문제가 있는 경우, 특히 배드섹터가 있는 경우
  • 계속적인 전원인가는 디스크의 상태를 악화시키며 복구시기를 놓치는 경우가 많이 있습니다.
  • 맥시스템의 구동되는 응용프로그램의 산출물은 특수한 파일구조로 구성되어있는 경우가 많습니다

 

?

조회 수 1161 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제

This is the fifth ATA/ATAPI standard. Released in 2000.

This standard specifies the AT Attachment Interface between host systems and storage devices. It provides a common attachment interface for systems manufacturers, system integrators, software suppliers, and suppliers of intelligent storage devices.

The application environment for the AT Attachment Interface is any host system that has storage devices contained within the processor enclosure.

This standard defines the connectors and cables for physical interconnection between host and storage device, as well as, the electrical and logical characteristics of the interconnecting signals. It also defines the operational registers within the storage device, and the commands and protocols for the operation of the storage device.

This standard maintains a high degree of compatibility with the AT Attachment with Packet Interface Extensions standard (ATA/ATAPI-4), NCITS 317-1998, and while providing additional functions, is not intended to require changes to presently installed devices or existing software.

?

조회 수 1101 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제

This is the sixth ATA/ATAPI standard. Released in 2001.

This standard specifies the AT Attachment Interface between host systems and storage devices. It provides a common attachment interface for systems manufacturers, system integrators, software suppliers, and suppliers of intelligent storage devices.

The application environment for the AT Attachment Interface is any host system that has storage devices contained within the processor enclosure.

This standard defines the connectors and cables for physical interconnection between host and storage device, as well as the electrical and logical characteristics of the interconnecting signals. It also defines the operational registers within the storage device, and the commands and protocols for the operation of the storage device.

This standard maintains a high degree of compatibility with the AT Attachment with Packet Interface - 5 standard (ATA/ATAPI-5), NCITS 340-2000, and while providing additional functions, is not intended to require changes to presently installed devices or existing software.

?

조회 수 1125 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제

This is the seventh ATA/ATAPI standard. Released in 2003.

This standard specifies the AT Attachment Interface between host systems and storage devices. It provides a common attachment interface for systems manufacturers, system integrators, software suppliers, and suppliers of intelligent storage devices.

The application environment for the AT Attachment Interface is any host system that has storage devices contained within the processor enclosure.

Volume 1 defines the register delivered commands used by devices implementing the standard.

Volume 2 defines the connectors and cables for physical interconnection between host and storage device, the electrical and logical characteristics of the interconnecting signals, and the protocols for the transporting commands, data, and status over the interface for the parallel interface.

Volume 3 defines the connectors and cables for physical interconnection between host and storage device, the electrical and logical characteristics of the interconnecting signals, and the protocols for the transporting commands, data, and status over the interface for the serial interface.

?

조회 수 2019 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부 수정 삭제

The set of AT Attachment standards consists of this standard and the ATA implementation standards described in ATA8-AAM. The AT Attachment ATA Command Set (ATA8-ACS) specifies the command set host systems use to access storage devices. It provides a common command set for systems manufacturers, system integrators, software suppliers, and suppliers of intelligent storage devices.

?

하드디스크
2011.03.16 14:47

Seagate RS-232 adapter schematic

조회 수 1219 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제

This is an adapter which allows you to connect a Seagate drive to the COM port, allowing to access TMOS using any terminal program.

An adapter which allows you to connect a Seagate drive to the COM port, allowing to access TMOS using any terminal program.

Connect GND to the ground (any wire in PC colored in black)

You can locate Tx and Rx by doing some experiments with jumper-pins of a drive.

?

조회 수 1169 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
Dir (for FAT16 and FAT32)



Catalog consists of 32 bytes records. These records describe files and catalogs inside catalog.

First two records in catalog (except root) describe this catalog and catalog located on upper level.

Shift Size Descryption
0-0 1 - The first symbol of file name имени (deleted - E5)
1-10 10 - Other 2-11 symbols of file name
11-11 1 - Attributes of file
12-12 1 - Reserved
13-13 1 - Time creation (tenth parts of second)
14-15 2 - Time creation (hours, minutes, seconds)
16-17 2 - Date creation
18-19 2 - Date of last usage
20-21 2 - MSB cluster
22-23 2 - Date of last modification (hours, minutes, seconds)
24-25 2 - Date of last record
26-27 2 - LSB cluster
28-31 4 - File size (0 for catalogs)

?

파일시스템
2011.03.16 14:06

FAT 파일시스템 FAT32 테이블 살펴보기

조회 수 16397 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
FAT32 table



FAT table is used for determination of condition of clusters and for searching next cluster of file or catalog.

One record about condition of cluster uses 4 bytes (32 bits) in FAT32.
The first sector of FAT32 table starts with signature F8 FF FF.
Free space is marked with signature 00 00 00 00. The end of the file is marked with signature FF FF FF F8 - FF FF FF FF. The damaged cluster is marked with signature FF FF FF F7 .

There is the special view of the first three sectors of FAT32 table on the picture above.
?

파일시스템
2011.03.16 14:05

FAT 파일시스템의 FAT 테이블 살펴보기

조회 수 1207 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 수정 삭제
FAT16 table



FAT table is used for determination of condition of clusters and for searching next cluster of file or catalog.

One record about condition of cluster uses 2 bytes (16 bits) in FAT16.
The first sector of FAT16 table starts with signature F8 FF.
Free space is marked with signature 00 00. The end of the file is marked with signature FF F8 - FF FF. The damaged cluster is marked with signature FF F7

There is the special view of the first three sectors of FAT16 table on the picture above.
?

Board Pagination Prev 1 2 3 4 5 6 Next
/ 6