[PLUG] problem with mdv 2010
o.s.h.o at guruvision.com
Wed Feb 17 03:51:57 PST 2010
On Wed, Feb 17, 2010 at 10:45 AM, Shridhar Daithankar
<ghodechhap at ghodechhap.net> wrote:
> On Wednesday 17 February 2010 16:04:03 म.हा.सा.ग.र wrote:
>> Everything just works purrrrfect.. till we change to ext5 of-course!
> There won't be any ext5. btrfs is coming up next. and if you are using ext4,
> make sure that you use auto_da_alloc otherwise in case of power failures, lots
> of files will be left with zero bytes.
> /dev/sdan / ext4 auto_da_alloc,noatime,defaults 0 1
>> With slower computer and lesser memory i am getting almost similar
>> performance... wondering what must be the reason... :-)
> that they are slow? I have two disks, one gives 130MB/s and other one 70MB/s.
> Filesystem is not going to matter in that case.
# Entry for /dev/sda2 :
UUID=c70882a3-96bd-429a-baap-0ead59c51379 / ext4 auto_da_alloc,noatime 1 1
after your *mition constructive criticism* suggestion.
Hope this would sail me through प्रलय of 2010
i searched and found following x-प्ल-नेशन upon googling for your suggestion:
auto_da_alloc(*) Many broken applications don't use fsync() when
noauto_da_alloc replacing existing files via patterns such as
fd = open("foo.new")/write(fd,..)/close(fd)/
rename("foo.new", "foo"), or worse yet,
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
If auto_da_alloc is enabled, ext4 will detect
the replace-via-rename and replace-via-truncate
patterns and force that any delayed allocation
blocks are allocated such that at the next
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
blocks are forced to disk.
१. Stupid question always warrants a stupid answer!
२. No question is ever stupid!
More information about the plug-mail