Если есть время, то можно почитать некоторые мысли Jim Nelson на UT (для доступа к оригиналу - нужна регистрация на UT):

Happy reading!
Jim NelsonHopefully, by the end of this thread, we can all gain a clearer and accurate understanding of how data is physically stored on a HD and how it is retrieved/written for use in programs. The idea is that people who KNOW will contribute corrections or clarifications as may be needed. I will then produce a final document incorporating "the true story of an I/O operation" and mark it as the solution for the thread.
I'll get it started by describing my understanding of this stuff...

PHYSICAL storage
I am sure that SCSI uses "fixed block architecture" (FBA) for physical storage of bytes on disk and I believe that all other HDs protocols use it too.
I understand that FBA means that all user writeable/readable data areas are fixed and predetermined and equal in length (byte capacity). I also understand that FBA involves some pre-defined "control" data stored in specific area(s) of the drive during manufacturing. These areas are used for things like head alignment and cylinder/track positioning and error detection/correction, etc.

A HD is built using round "platters" on which ferrous material is carefully deposited, typically on both the top and the bottom of each platter. Each platter can therefore provide two surfaces on which data can be written/read.

Each platter has a fixed number of "tracks" and it is in these tracks that data is actually stored. Each track is a minute width and runs in a circle around the entire platter, essentially joining itself to form an unbroken area around the platter. Platters being round, each track is actually a slightly different length and it can be viewed that the inner tracks are both shorter and move more quickly than the outer tracks. However, ALL tracks have the same number of fixed blocks.

A "cylinder" refers to a vertical relationship of platters and their tracks. Allow a platter with 10,000 tracks on each of its two recording surfaces and allow the identification of those tracks as being numbered from 1 to 10,000 from the inner-most track to the outermost track. This hypothetical device will then have 10,000 "cylinders" and each cylinder will be composed of two tracks. So cylinder #768 will be composed of track #768 of the top of the platter and track #768 of the bottom of the platter. In a similar device with 3 platters there would still be 10,000 cylinders but now each cylinder would be composed of six tracks, each of those tracks being the ones in direct vertical line with the one above it.
I don't know if "cylinders" are actually material in a FBA device but I assume that they are. My guess is that cylinders constitute the order in which data files are written. For example, a file would be written to cyl-1, trk-1, cyl-1, trk-2, cyl-2, trk-1, cyl-2, trk-2 in a two-platter device.

Data storage is totally unaffected by block (as in FBA) 'boundaries' and each block is always filled to the fullest. Of course the last data block for an application may well leave some portion of a (FBA) block unfilled. The main point to be made here is that the (FBA) block size is totally independent of application record size or block size that an application may choose to use so an application "block" may span several FBA blocks or there may be several application "blocks" (including a part of a "block" at the start/end) within one FBA block.

LOGICAL storage
I believe that the file system's design and its limitations constitute the primary factor of logical storage and that these are completely independent of device physical storage except as regards the total byte capacity of a HD.
For instance the "cluster size" of a specific HD will vary depending on if the file system is FAT or FAT-32 or NTFS or HPFS. In fact FAT can only handle a small HD byte capacity compared to the size of drives available today. it is relevant to note here that a drive can be "partitioned" to improve its storage 'efficiency' and in such a case this part of the discussion is applicable to a "partition" as opposed to the (whole) physical drive. This "cluster size" forms the minimum size that any file system will write and constitutes its chosen "block size" for a specific device. Accordingly, if a "cluster size" of 32,767 bytes is in effect for a given drive (or partition) then a file of 10 bytes will be "occupy" 32,767 bytes, a file of 32,000 bytes will occupy 32,767 bytes and a file of 32,768 bytes will occupy 65,534 bytes.

The file system maintains a consistent logical representation of what it has stored on the HD (or partition of the HD). It is the file system controlling I/O on the system where the data is physically stored that actually performs the work involved.
I can't relate the specific details, but have surmised the following:
a) The file system need know nothing about the physical storage mechanism other than its capacity. I suspect that the device must also be a FBA device.
b) It seems like the file system needs to know of the existence of partitions, and their precise sizes, so that it can accurately determine the exact (physical) offset for files in specific partitions. My guess is that this would be a number stored in the file system's 'control' data and that it is simply added to the calculated cluster value on each read/write.
c) Folders (directories and sub-directories) are a special portion of the file system used to facilitate identification by users are are hardly relevant to this discussion.
d) There is some protocol for record locking that is universally applied within a file system.
--- Don't know if this is applicable to locking of the header of a Visual FoxPro table.
e) Files have several descriptive factors stored about each of them and the relevant ones here are:
--- Length of the file in bytes;
--- Start of file cluster number;
--- Number of clusters from the start cluster;
--- . . . and when the number of clusters above does not satisfy the files' byte length, additional information to define the next cluster(s) start number(s) and count(s).

Since the file system works on a fixed cluster size for the drive (or partition) it is a simple matter for it to "instruct" the physical drive to 'read X bytes for me starting at byte Y and place them in (RAM) location Z. For a non-fragmented file it can do this in one operation but a fragmented file would require as many reads as there are fragments assuming that the whole file is wanted. Note, too, that some devices (SCSI for sure) can accept multiple offsets in a single read operation, though the file system also has to be smart enough to "construct" the read request to make use of this.
A write operation is similar, though in this case the file system first has to determine what cluster the write is to start at and, if there is not sufficient room from that cluster number to contiguously write the whole record (file) then it must construct multiple operations and execute each of those (or a special 'multiple-write' operation if it is capable) and confirm completion.
In either case the HD electronics can convert the starting byte value to a cylinder/head/record (block) and be governed according to the operation requested.

Applications like Visual FoxPro undoubtedly do not read all files in whole (MS Word, for instance, would want to read a whole document, and possibly several, at a time). Accordingly, the file system accommodates an application's reading or writing whatever portions of a file it wishes to.
The following suggests that the actual I/O operations are handled within the file system. That may be incorrect but I don't think it matters for what is being discussed.
Things get highly speculative here (even more than previous < s >)

I assume that Visual FoxPro typically physically reads and writes for at least full clusters of data.
I assume that Visual FoxPro defines this requirement in the form of offset(s) within a specific table or .CDX or .FPT and that the file system would use the file handle to obtain the file's actual positioning (logically) on the HD or partition.
I assume that Visual FoxPro stores this data in its "cache" and that it either doles out a copy of the specific record in process or points to the specific record's starting position within its cache. It seems reasonable to assume that it definitely uses a copy when buffering is in effect.
I assume that Visual FoxPro writes a full cluster when it updates/writes record(s), with the exception of the last one, when I suppose that it writes only for the real data length.
It seems true that certain commands can force Visual FoxPro to (re)read/(re)write data. Commands like FLUSH, UNLOCK, GOTO and RECCOUNT() have been attributed with this capability. In addition SETs like LOCK and REFRESH can affect this.

The full sequence of a write is along the lines of:
1) Visual FoxPro is "signalled", either by filling a cluster-worth or by some application command or SET value, to write some data for a specific table (and/or .CDX and/or .FPT).
2) Visual FoxPro prepares (a) write request(s), forwards it/them to the file system, then waits for notification of completion.
3) The file system "translates" the write instruction(s) so that it/they will occur at the correct position(s) on the HD or partition.
4) The file system then gives the (translated) request(s) to the physical HD to execute and waits for successful completion(s).
5) The HD electronics "translates" each request to the actual cylinder/head/record(s) and performs the write operation, which probably includes writing some ECC data to the "control" portion of the drive for the specific area.
6) When the electronics receives the signal that the write is completed the same data is then re-read to verify success.
7) Assuming success of the physical write, the file system is notified of successful completion.
8) When ALL writes that the file system issued to the HD in connection with the original Visual FoxPro request(s) are returned as successful by the HD, the file system returns a successful completion to Visual FoxPro.
9) Visual FoxPro can then proceed with executing the application.
NOTE: there are many opportunities for cacheing in the above. Some could be:
a) Within 1 and 2 above, Visual FoxPro might move the data in question to a specific buffer area and refer the operations to use that data for the write(s).
b) In 3 above the file system might want to make its own copy of the data to be written.
c) In 5 above the data is almost certainly cached in storage within the HD control electronics.

The relevance of an "EOF MARKER" for Visual FoxPro is unknown to me. In some cases I read that there seems to be one and that it matters a lot yet in other instances a situation is described where one seems to be irrelevant. It appears that Visual FoxPro could get along nicely without such a marker.

PLEASE... correct, amplify or clarify as may be necessary to create a whole and accurate picture of the process.

А вот немного про транзакции в сети - ответ оппонента... Удивительно, что представители компании Microsoft в дискуссии не участвовали...

Peter StordiauNo, I can't agree with it being legitimate that a record will be re-written (should be re-written) when the record is still being locked. Remember, this has all to do with app-logic, and the developer has to be (able to) depend on the logic on "transactions". It is therefor offical(ly known) that records won't flush until the unlock (with the table concerned being active (Select)), and an UNLOCK ALL will imply the logical transaction. Also do not forget that Novell once (still ?) anticipated formally on XBase's working by TTS (Transaction Tracking System) incorporating with XBase (possibly this was FoxBase/FoxPro only). TTS could deal with implicit transactions by means of RLock - Unlock only, and it could deal with explicit transactions by means of commands as BEGIN TRANSACTION, ROLLBACK, COMMIT etc., and Novell came with a Fox Library especially for this;
We talk about the implicit transactions here.
Sidenote : the implicit transactions will still be supported by means of TTS still existing, but I am sure that it just doesn't work. Or because of Novell's improper working on TTS itself, or because of Visual FoxPro not dealing with it properly, like flushing the record(s) out of the developer's control ...

MaestroEv Жалко, что и фокс и виндовс вроде же от одной команды, что ж они не сделают систему транзакций на стороне сервера хотя бы для своих же продуктов.. Acces, VFp, Basic...Это сделано скорее всего по "идеологическим соображениям", чтобы вынудить нас купить MS SQL Server...

MaestroEvИли мож есть что-нибудь переносящее работу по ТТС на сторону сервера..? Здесь два возможных пути:
1. Использование данных на сервере с помощью COM+ (я уже давано использую для этих целей Web Services + стандартная буферизация + транзакции, которые есть в самом FoxPro). Идеология написания программ полностью подчиняется идеологии клиент-сервер и более медленная, чем привычный файл-серверный подход...

C 9 версии можно производить транзакции и со свободными таблицами - но пока не пробовал, так как данная операция не совместима со старыми версиями FoxPro.

2. Использование terminal-services (например, Citrix). Беседовал с одним товарищем из Австралии - у них порядко 500 одновременно работающих пользователей с базами данных FoxPro через эту службу (плюс 70 в локальной сети). Проблем нет, но их специфика работы позволяет производить архивацию, упаковку и перестройку индексов в течении ночи...

P.S. На e-mail постараюсь ответить в выходные...

Igor Korolyov
Hi Sergey!
Не очень хоошая статья ... Как говорится, чем богаты... К сожалению, мне пока не удалось найти подробное описание данного процесса от Microsoft (автор в конце вопросом открыает дискуссию, которая в оргинали имела место и ссылку для интересующихся я привел)... В связи с изменениями полититики MS в сторону открытости может еще удастся это сделать в скором будущем... А так все это пока напоминает "гадание на кофейной гуще"... Хотя с точки зрения прикладного программирования транзакции делают то, что мы от них хотим...

But anyway, good luck!

I_Am222 Кстати тот же пример (обмусоливается на фоксклубе - 500 000 апдейтов) - к сожалению показал, что в таких дозах увы - транзакция не работет так как нужно
Не совсем верно... Не работает обновление после завершения транзакции. Это как раз непредсказуемый момент о котором мы знаем достоверно только одно - он должен быть как можно короче. И не факт, что не произойдет разрушение целостности промышленной базы данных, просто Ваши оппоненты в "Сравнении СУБД" об этом умышленно умалчивают. Законы физикик еще никто не отменял и изменения для ускорения как правило осуществляются в памяти и ее содержание как и в FoxPro еще должно быть корректно сброшено на диск. Другое дело, что в этих больших СУБД, зная эту проблему компьютеров, ведутся еще параллельно файлы, которые называют логи и сделано все возможное, чтобы сбрасывать содержание памяти на диск (в Oracle есть даже параметры которые регулируют этот процесс)... Но все эти большие СУБД ничего не знают, например о физической организации RAID array, соответсвенно СУБД будет думать, что буфер будет записан, а на самом деле он будет в кэше то есть в памяти...

Тема эта долгая и вылилась во много страниц в соответсвующем тематическом форуме. Нам же просто надо соблюдать требования к аппаратному обеспечению, применять обработку данных на сервере (если данные очень критичны) и используя голову писать простые и прозрачные программы (а так-же регулярно делать копии, на которых "зациклины" все нормальные админы больших СУБД)... При соблюдении этих простых правил - FoxPro работает годами без единого сбоя и очень быстро...

Good luck!

I_Am222И вся эта война, повторяет ту...
К сожалению, мы должны участвовать в этих "не совсем умных" "войнах", потому как постоянно появляются люди, оторванные от реальной жизни, не написавшие в жизни ни одного законченного реального приложения для реального клиента и желающие поразмять пальцы... Нам надо участвовать, чтоб все знали, что "Fox еще жив, развивается и молодое поколение знало, что есть еще что-то помимо того, что им пичкают на занятиях в их учебных заведениях"...

Good luck!