Unit Instance

HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/boooks_handbook/pt_BR/?format=api",
    "source": [
        "Historically, the default behavior was to write out meta-data updates synchronously. If a directory changed, the system waited until the change was actually written to disk. The file data buffers (file contents) were passed through the buffer cache and backed up to disk later on asynchronously. The advantage of this implementation is that it operates safely. If there is a failure during an update, meta-data is always in a consistent state. A file is either created completely or not at all. If the data blocks of a file did not find their way out of the buffer cache onto the disk by the time of the crash, <citerefentry><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry> recognizes this and repairs the file system by setting the file length to <literal>0</literal>. Additionally, the implementation is clear and simple. The disadvantage is that meta-data changes are slow. For example, <command>rm -r</command> touches all the files in a directory sequentially, but each directory change will be written synchronously to the disk. This includes updates to the directory itself, to the inode table, and possibly to indirect blocks allocated by the file. Similar considerations apply for unrolling large hierarchies using <command>tar -x</command>."
    ],
    "previous_source": "",
    "target": [
        "Historicamente, o comportamento padrão era gravar atualizações de metadados de forma síncrona. Se um diretório fosse alterado, o sistema aguardava até que a alteração fosse gravada no disco. Os buffers de dados do arquivo (conteúdo do arquivo) foram passados pelo cache de buffer e foram copiados para o disco posteriormente de maneira assíncrona. A vantagem dessa implementação é que ela opera com segurança. Se houver uma falha durante uma atualização, os metadados estarão sempre em um estado consistente. Um arquivo é criado completamente ou não é de todo. Se os blocos de dados de um arquivo não encontrarem saída do cache de buffer para o disco no momento da falha, o <citerefentry><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry> reconhece isso e repara o sistema de arquivos definindo o comprimento do arquivo como <literal>0</literal>. Além disso, a implementação é clara e simples. A desvantagem é que as alterações nos metadados são lentas. Por exemplo, <command>rm -r</command> toca todos os arquivos em um diretório sequencialmente, mas cada alteração de diretório será gravada de forma síncrona no disco. Isso inclui atualizações para o próprio diretório, para a tabela de inode e possivelmente para blocos indiretos alocados pelo arquivo. Considerações semelhantes aplicam-se ao desenrolar hierarquias grandes usando <command>tar -x</command>."
    ],
    "id_hash": 8192054654989336446,
    "content_hash": 8192054654989336446,
    "location": "book.translate.xml:23620",
    "context": "",
    "note": "(itstool) path: sect3/para",
    "flags": "",
    "labels": [],
    "state": 20,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 3871,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 190,
    "source_unit": "https://translate-dev.freebsd.org/api/units/123010/?format=api",
    "priority": 100,
    "id": 69625,
    "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/boooks_handbook/pt_BR/?checksum=f1b0064e2b397f7e",
    "url": "https://translate-dev.freebsd.org/api/units/69625/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2019-10-20T12:29:17.991781Z"
}