[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.
>
> --
> Regards
>  Shridhar
>


I have

# Entry for /dev/sda2 :
UUID=c70882a3-96bd-429a-baap-0ead59c51379 / ext4 auto_da_alloc,noatime 1 1

and similar,

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 mailing list