| View previous topic :: View next topic |
| Author |
Message |
FizzyWidget
Veteran
Joined: 21 Nov 2008
Posts: 1133
Location: 127.0.0.1
|
 Posted: Sun Jul 18, 2010 9:22 pm Post subject: Ext4 fstab and kernel 2.6.34 options |
 |
|
At the moment in my fstab i most my ext4 partitions with - noatime,data=ordered,journal_checksum,barrier=1 - i know there were a few performance issues in 2.6.33 kernel, have they all be resolved now, should i continue using the above line when i update the kernel or is there a better way?
I have googled a bit and found these mount options Cyker suggests - noatime,nosuid,commit=5,data=journal,journal_checksum,barrier=1
_________________
I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch. |
|
| Back to top |
|
 |
nexus780
Apprentice
Joined: 17 Sep 2004
Posts: 206
Location: Manchester
|
| Posted: Sun Jul 25, 2010 6:29 am Post subject: |
|
|
| I don't know much about FS tuning but personally I will be keeping data=ordered until I switch to btrfs. No performance gain could possibly justify the increased risk of not having =ordered, but your views/requirements may of course be different. Does anyone know what happened to the once-planned (I think it was proposed during .33-rc times) data=guarded? |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sun Jul 25, 2010 8:26 am Post subject: Re: Ext4 fstab and kernel 2.6.34 options |
|
|
| Carps wrote: | | At the moment in my fstab i most my ext4 partitions with - noatime,data=ordered,journal_checksum,barrier=1 |
data=ordered and barrier=1 are defaults for ext4 mounts.
| Carps wrote: | | Cyker suggests - noatime,nosuid,commit=5,data=journal,journal_checksum,barrier=1 |
BTW commit=5 is also the default.
I additionally agree with nexus780 about data=ordered far preferable to data=journal
Apart from this, what I understood for journal_checksum was that
| Documentation/filesystems/ext4.txt wrote: | | This will allow the recovery code in e2fsck and the kernel to detect corruption in the kernel |
=> I do not understand its interest on a non-boot partition.
I might be wrong about this. 
Now, to answer more precisely your question, I fear there has been no noticeable improvement on ext4 with 2.6.34, you can crosscheck here : http://kernelnewbies.org/LinuxChanges#head-9d706e4c99e6f89cafc5b9536c948de6b84d351e |
|
| Back to top |
|
|
d2_racing
Bodhisattva
Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada
|
| Posted: Sun Jul 25, 2010 2:31 pm Post subject: |
|
|
I have this /etc/fstab for a long time :
| Code: |
# <fs> <mountpoint> <type> <opts> <dump/pass>
/dev/sda7 /boot ext2 noauto,noatime 1 2
/dev/sda8 / ext4 defaults,noatime 0 1
/dev/sda9 none swap sw 0 0
none /dev/shm tmpfs nodev,nosuid,noexec 0 0
/dev/sda1 /mnt/win_c ntfs defaults,ro,user,nls=iso8859-1,nls=utf8,umask=0 0 0
/dev/sda2 /mnt/win_d ntfs defaults,ro,user,nls=iso8859-1,nls=utf8,umask=0 0 0
/dev/sda5 /mnt/win_e ntfs defaults,ro,user,nls=iso8859-1,nls=utf8,umask=0 0 0
/dev/sda6 /mnt/pont vfat defaults,rw,user,umask=0 0 0
# shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
|
I don't use any tweak for ext4 , should I ? |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sun Jul 25, 2010 7:28 pm Post subject: |
|
|
| d2_racing wrote: | | I don't use any tweak for ext4 , should I ? |
Bien évidemment non d2 ! 
As we have seen, the two most important options (data=ordered and barrier=1) are default settings.  |
|
| Back to top |
|
|
d2_racing
Bodhisattva
Joined: 25 Apr 2005
Posts: 13047
Location: Ste-Foy,Canada
|
| Posted: Sun Jul 25, 2010 7:42 pm Post subject: |
|
|
Nice then  |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 25, 2010 8:36 pm Post subject: |
|
|
| aCOSwt wrote: | | As we have seen, the two most important options (data=ordered and barrier=1) are default settings. |
I would suggest to add at least journal_checksum. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Jul 25, 2010 8:43 pm Post subject: Re: Ext4 fstab and kernel 2.6.34 options |
|
|
| aCOSwt wrote: | | Documentation/filesystems/ext4.txt wrote: | | This will allow the recovery code in e2fsck and the kernel to detect corruption in the kernel |
=> I do not understand its interest on a non-boot partition. |
I see this description for the first time and must say that this explanation is rather stupid. The real purpose of journal_checksum is that it will allow to detect if the journal was damaged. In fact, without journal_checksum, having a journal or not makes almost no difference for data integrity, and moreover having a journal could be even worse: If you have a powerloss during writing of a journal, then after the next boot, the filesystem will happily replay whichever rubbish was written into the journal - which could destroy many different things on your partition, if the powerloss caused writing "random" data. With a checksum, chances are high that the journal is detected as broken and not replayed in such a case. |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sun Jul 25, 2010 9:41 pm Post subject: Re: Ext4 fstab and kernel 2.6.34 options |
|
|
| mv wrote: | | I see this description for the first time and must say that this explanation is rather stupid. |
Which is the reason why I have some doubts about my understanding.
However :
| mv wrote: | | If you have a powerloss during writing of a journal, then after the next boot, the filesystem will happily replay whichever rubbish was written into the journal |
Why would it do so ? If the power failure occurs during the writing of the journal, it means that the real data has already been written (data=ordered) and is in good condition with no need to replay the journal.
I agree that, in cyker suggestion (data=journal), as he, surprisingly to me, seems to put more emphasis on the journal than on the real data, adding journal_checksum might appear coherent. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Jul 26, 2010 8:51 pm Post subject: Re: Ext4 fstab and kernel 2.6.34 options |
|
|
| aCOSwt wrote: | | If the power failure occurs during the writing of the journal, it means that the real data has already been written (data=ordered) and is in good condition with no need to replay the journal. |
You are misunderstanding the term "data" here: "data" refers here only to the content of the file, not to the metadata (like e.g. the information where the file finds this data). This metadata cannot be written before it is written in the journal - it is the whole point of the journal that this metadata is written first into the journal and only afterwards to the disk so that (if there is powerloss in the last step) the journal can be replayed. |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Tue Jul 27, 2010 9:27 am Post subject: Re: Ext4 fstab and kernel 2.6.34 options |
|
|
| mv wrote: | | You are misunderstanding the term "data" |
I am afraid that this is not the only thing I am misunderstanding...
| mv wrote: | | This metadata cannot be written before it is written in the journal |
That is actually the main point.
However, my understanding about it is that, with "data=writeback" the metadata will certainly be written in the fs, before it is written in the journal.
And that, with "data=ordered", because of the delayed allocation mecanism, metadata will almost certainly be commited before the data is written, hence before metadata is commited to the journal.
If one want to ensure the behaviour you describe, then the filesystem sould specifically be mounted nodelalloc.
This implying a significant performance loss.
Maybe is this what Carps was refering to.
I remember a rather hot thread about this, last year, on thread.gmane.org opposing Linus Torvald ready to come back to ext2 because of this  to T'Tso who gave up rather angrily... |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Jul 27, 2010 8:07 pm Post subject: Re: Ext4 fstab and kernel 2.6.34 options |
|
|
| aCOSwt wrote: | | However, my understanding about it is that, with "data=writeback" the metadata will certainly be written in the fs, before it is written in the journal. |
No, the metadata will always be written to the journal before it is written into the filesystem. As mentioned previously, this is the main point of having a journal.
| Quote: | | And that, with "data=ordered", because of the delayed allocation mecanism, metadata will almost certainly be commited before the data is written, hence before metadata is commited to the journal. |
No. What you describe here is exactly the behavior of "data=writeback" in contrast to "data=ordered".
| Quote: | | If one want to ensure the behaviour you describe, then the filesystem sould specifically be mounted nodelalloc. |
No. This delayed allocation is another story. It means that writing data of certain files (but also the corresponding metadata corresponding to that data) is delayed until the filesystem driver is sure that this can be done in an effective manner (or until a certain timeout is reached). This means that commands which are sent later are possibly written earlier. This shouldn't be a problem if the filesystem driver were clever enough to not postpone the order for a related change in metadata, e.g. if writing to some new file and renaming back to some old file, it is bad if the renaming (which causes a deletion) is postponed until the data to that file (and the corresponding metadata) was successfully written, since otherwise a crash can cause only the deletion and loss of the newly written file. In early ext4 version some of such implicit dependencies were forgotten which cause data loss especially for KDE configuration files which are written in that way. Fortunately, this is meanwhile fixed in ext4. |
|
| Back to top |
|
|
nexus780
Apprentice
Joined: 17 Sep 2004
Posts: 206
Location: Manchester
|
| Posted: Wed Jul 28, 2010 9:22 am Post subject: |
|
|
This may be a stupid question, but with this stuff I'd much rather be safe than sorry...
Can somebody just say explicitly that, when using data=ordered, using journal_checksum is pointless? Does this apply even if the underlying disk drive is returning incorrect data? |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Wed Jul 28, 2010 1:03 pm Post subject: |
|
|
| nexus780 wrote: | | Can somebody just say explicitly... |
Despite we do not agree... I hardly see how mv and I could be more explicit...
I agree with mv about what should be done, we do not agree about what is actually done.
But I admit I cannot find my way to an up to date status on this story.
In order to image how it is actually hard to find the way (which could definitely answer your question), let's consider :
Before knowing weather the journal_checksum mount option is theoretically interesting or not, let's try to know if this option is safe :
Explicit and factual answer : NO !
NO ?
Well... not quite... !
Definitely not with 2.6.32-r1 (Bug 14354)
This bug has been said fixed !
How ?
"It's fixed in mainline as of commit d4da6c9 when Linus reverted commit d0646f7.
Users could still see it if they mount a file system with -o journal_checksum, but (a) it's no longer the default, and (b) corruption if you use the non-default journal_checksum mount option is not a regression."
In other words, journal_checksum was a default option and generating corruption. Let's no longer make it default and... the bug can be closed...
Well, it is said about this bug that fixes have been made in 2.6.33 in order to make journal_checksum safer...
To which extent ? As you can see that journal-checksum did not come back as a default option... What is the level of faith you can get ? 
My own personal explicit opinion is : journal_checksum ? No !
Considering the way we have seen things are managed around ext4, sticking to default settings appears logically to me the best bet.
defaults, vg : data=ordered - commit=5 - barrier=1 - orlov - bsddf - data_err=ignore - nogrpid - bh - delalloc - auto_da_alloc - nodiscard
Who can be more explicit about this ? Linus Torvalds when he writes about ext4 in march 2009 :
"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."
Or if you prefer T'tso himself answering Linus ?
"People can call file system developers idiots if it makes them feel better --- sure, OK, we all suck. If someone wants to try to create a better file system, show us how to do better, or send us some patches."
Well then nexus780, surely explicit but, if with that word you meant "a definitive answer" I fear that...
We are not out of the wood yet.
=======
@mv, | mv wrote: | ...No. What you describe here is exactly the behavior of "data=writeback" in contrast to "data=ordered"...
No. This delayed allocation is another story. |
I 100% would like to agree with you mv however, here is a quote from T'tso march 09 :
"You are right that data=writeback and delayed allocation do both mean that data can get pushed out much later than the metadata."
From which I deduce that data=ordered + delalloc => [ 1/ metadata commited in the fs - 2/ data commited to the fs - 3/ metadata commited to the journal ] is a possible sequence. |
|
| Back to top |
|
|
nexus780
Apprentice
Joined: 17 Sep 2004
Posts: 206
Location: Manchester
|
| Posted: Thu Jul 29, 2010 9:56 am Post subject: |
|
|
Yes ext4 certainly has seen some odd decisions in its life
But thanks for your reply, that cleared things up  |
|
| Back to top |
|
|
FizzyWidget
Veteran
Joined: 21 Nov 2008
Posts: 1133
Location: 127.0.0.1
|
| Posted: Thu Aug 19, 2010 4:38 pm Post subject: |
|
|
so basically remove all the settings i have there now and just go with defaults,noatime ?
_________________
I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
