Доброго!Тобто, якщо напруга впаде в цей самий період синхронізації, то, поточні данні будуть втрачені (але не данні попередньої синхронізації).
несподіванкою стало відсутність засобів дефрагментаціїї
спасибі, дуже гарне пояснення. а є ж ніби можливість на рівні юзера регулювати отой час, після якого дані скидаються з кешу на диск? може хтось нагадати, де це робиться?
How aggressively the system writes things back out to disk can be controlled via some tuning parameters, in particular /proc/sys/vm/dirty_expire_centisecs and /proc/sys/vm/dirty_writeback_centisecs. The latter, in particular will be adjusted by laptop_mode and other tools that are trying to extend battery lifespans.
So, why wasn't this a problem before in the past? Well, ext3 by default has a commit interval of 5 seconds, and has data=ordered. What does this mean? Well, every 5 seconds, the ext3 journal is committed; this means that any changes in since the last commit are now guaranteed to survive an unclean shutdown. The journalling mode data=ordered means that only metadata is written in the journal, but data is ordered; this means that before the commit takes place, any data blocks are associated with inodes that are about to be committed in that transaction will be forced out to disk. This is primarily done for security reasons; if this was not done, then any newly allocated blocks might still contain previous data belonging to some other file or user, and after a crash, accessing that file might result in a user seeing someone else's mail or p0rn, and that's unacceptable from a security perspective.However, this had the side effect of essentially guaranteeing that anything that had been written was guaranteed to be on disk after 5 seconds. (This is somewhat modified if you are running on batteries and have enabled laptop mode, but we'll ignore that for the purposes of this discussion.) Since ext3 became the dominant filesystem for Linux, application writers and users have started depending on this, and so they become shocked and angry when their system locks up and they lose data --- even though POSIX never really made any such guaranteed.
Цитата несподіванкою стало відсутність засобів дефрагментаціїїнавіщо вам дефрагментація??
Цитата: noddeat від 2009-03-09 14:54:18Цитата несподіванкою стало відсутність засобів дефрагментаціїїнавіщо вам дефрагментація?? Прибування в "Віндовс" на ntfs (та відсутність альтернатив окрім FAT, де дефрагментація є складовою працездатності) та можливість реалізувати вибір в "Линукс", підштовхує до новаторства та експерименту (для остаточного вибору).
Проблема в тому, що XFS (ext4 не пробував ще) може попсути файл через те, що метадані файла були оновлені (напр. ім’я файлу вже змінилося) а дані у файлі - ще ні. В результаті частина файла виходить попсута - кілька блоків можуть бути забиті нулями.
Ні, в xfs це є security feature -- нулі (а не сміття) народжуються при відкачуванні журналу там, де виникає підозра на потрапляння "чужих" блоків (щоб уникнути leak'ів конфіденційної інформації).
Date Tue, 24 Mar 2009 10:55:40 -0700 (PDT)From Linus Torvalds <>Subject Re: Linux 2.6.29On Tue, 24 Mar 2009, Theodore Tso wrote:> > Try ext4, I think you'll like it. :-)> > Failing that, data=writeback for single-user machines is probably your> best bet.Isn't that the same fix? ext4 just defaults to the crappy "writeback" behavior, which is insane.Sure, it makes things _much_ smoother, since now the actual data is no longer in the critical path for any journal writes, but anybody who thinks that's a solution is just incompetent. We might as well go back to ext2 then. If your data gets written out long after the metadata hit the disk, you are going to hit all kinds of bad issues if the machine ever goes down. Linus
Date Tue, 24 Mar 2009 12:17:42 -0700 (PDT)From Linus Torvalds <>Subject Re: Linux 2.6.29On Tue, 24 Mar 2009, Kyle Moffett wrote:> > Regardless of any journalling, a power-fail or a crash is almost> certainly going to cause "data loss" of some variety.The point is, if you write your metadata earlier (say, every 5 sec) and the real data later (say, every 30 sec), you're actually MORE LIKELY to see corrupt files than if you try to write them together.And if you write your data _first_, you're never going to see corruption at all.This is why I absolutely _detest_ the idiotic ext3 writeback behavior. It literally does everything the wrong way around - writing data later than the metadata that points to it. Whoever came up with that solution was a moron. No ifs, buts, or maybes about it. Linus
Автор
Гілка: Чому Ext4, XFS і Btrfs можуть втрачати файли (Прочитано 4163 раз)
