| View previous topic :: View next topic |
| Author |
Message |
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
 Posted: Mon Feb 23, 2009 11:53 am Post subject: |
 |
|
Method 5:
Wait for btrfs.  |
|
| Back to top |
|
 |
neuron
Advocate
Joined: 28 May 2002
Posts: 2371
|
| Posted: Wed Feb 25, 2009 10:19 am Post subject: |
|
|
| anyone know if ext4 has file local fsync yet? |
|
| Back to top |
|
|
HotBBQ
Apprentice
Joined: 03 Mar 2004
Posts: 275
Location: West Melbourne, FL
|
| Posted: Mon Mar 02, 2009 4:02 pm Post subject: |
|
|
I've got ext4 up and running nicely on my system thanks to the SystemRescueCD. I was curioius as to the possibility of resizing some partitions using gparted without destroying the data. All of the partitions (/net, /home, /) are ext4. Is this possible? Also, is there a ext4 tweaking guide anywhere?
_________________
"If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." -- James Madison |
|
| Back to top |
|
|
milomak
Apprentice
Joined: 10 Apr 2008
Posts: 287
|
| Posted: Mon Mar 16, 2009 5:25 pm Post subject: |
|
|
| what happens if you create a ext3 partition, install as per normal. then convert that partition to ext4? |
|
| Back to top |
|
|
HotBBQ
Apprentice
Joined: 03 Mar 2004
Posts: 275
Location: West Melbourne, FL
|
| Posted: Mon Mar 16, 2009 5:34 pm Post subject: |
|
|
| milomak wrote: | | what happens if you create a ext3 partition, install as per normal. then convert that partition to ext4? |
From what I have read you will gain most of the performance improvements and maintain forward compatibility. If you enable extents, though, you will lose that compatibility. Furthermore, the extents will only apply to new files, not existing ones.
_________________
"If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." -- James Madison |
|
| Back to top |
|
|
garlicbread
Apprentice
Joined: 06 Mar 2004
Posts: 182
|
| Posted: Sun Mar 22, 2009 12:34 pm Post subject: |
|
|
I thought I'd post this here as it might be of interest to someone
I've currently got a laptop setup under ext3 at the moment,
and I'm in the process of building a second machine / HD (my Work PC) using ext4
by chroot'ing onto the disk directly from the laptop via a USB enclosure
I noticed this recently on slashdot
http://linux.slashdot.org/article.pl?sid=09/03/19/1730247
which follows onto posts here and here
http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892
http://thread.gmane.org/gmane.comp.file-systems.ext4/12179
so far I've only been using emerge / console commands to build the system which probably shouldnt't have an issue with fsync
but I figured as soon as I'd use kde4 on the new system (or perahps any form of kde)
this could potentialy be an issue due to fsync
I'm now using "-o data=alloc_on_commit" in the fs options just to be on the safe side when mounting the ext4 system
for info here is the patch I've been using against gentoo-sources-2.6.28-r4
(slightly modified to patch against 2.6.28.9 instead of ext4 git)
Edit
-- patch removed as it doesn't work --
Last edited by garlicbread on Mon Mar 23, 2009 9:47 pm; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Mar 23, 2009 6:26 am Post subject: |
|
|
| garlicbread wrote: | I'm now using "-o data=alloc_on_commit" in the fs options just to be on the safe side when mounting the ext4 system
for info here is the patch I've been using against gentoo-sources-2.6.28-r4
(slightly modified to patch against 2.6.28.9 instead of ext4 git) |
The patch appears to work as long as there is no "data=alloc_on_commit" in the fstab of the root filesystem. When the latter is the case, it won't remount root rewritable: | Code: | | mount -o remount,rw / |
complains about illegal option. Is this a bug in the patch or have I missed something else (e.g. is the kernel parameter rootfstype=ext4 not enough in this case)? Has anybody else observed this issue? |
|
| Back to top |
|
|
garlicbread
Apprentice
Joined: 06 Mar 2004
Posts: 182
|
| Posted: Mon Mar 23, 2009 7:43 pm Post subject: |
|
|
from what i understand the patch isn't used unless "data=alloc_on_commit" is in the filesystem options
without it the patch is fairly redundent (not switched on) as your using a different / default data allocation mode
I think it only really applies for apps that have trouble with fsync such as kde, and even then only when the system crashes and restarts
(could result in some of kde's config files being 0 length)
stuff at the console should be fairly safe i'd guess as it probably handles fsync properly
I just tried "mount -o remount,rw /" inside a chroot from the machine I'm using to build from and it seemed to work okay inside the chroot
I haven't gotten as far as booting with the system yet (still building several hundred packages from a copied world file) but I'll look out for this, probably try it inside the sabayon boot cd
for info I'm going to be using an initial 1Gb boot partition (typically ext3) to get around any issues with grub or the initial boot loader |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Mar 23, 2009 9:02 pm Post subject: |
|
|
| garlicbread wrote: | | from what i understand the patch isn't used unless "data=alloc_on_commit" is in the filesystem options |
Yes, as I said: I have problems only if I use the patch and put "data=alloc_on_commit" in the filesystem options for "/" (which is ext4) in my /etc/fstab. When I use instead "data=ordered" for "/" in /etc/fstab there is no such problem, of course (no matter of whether I use the patch or not). Moreover, the patch causes no problems if I put "data=alloc_on_commit" in /etc/fstab for other ext4 partitions (different from "/") - only for "/" there is this strange problem that it cannot be remounted (I experimented whether I could remount such other partitions as ro and then again as rw - no problem; only "/" has this problem).
| Quote: | I think it only really applies for apps that have trouble with fsync such as kde, and even then only when the system crashes and restarts
(could result in some of kde's config files being 0 length)
stuff at the console should be fairly safe i'd guess as it probably handles fsync properly |
That's true. However, I would hate myself if I loose kde configuration or perhaps even some text file I was editing (in case my editor does not handle fsync properly) just because I was too lazy to use a patch which was recommended by the ext4 maintainer. |
|
| Back to top |
|
|
garlicbread
Apprentice
Joined: 06 Mar 2004
Posts: 182
|
| Posted: Mon Mar 23, 2009 9:46 pm Post subject: |
|
|
scrap that patch it doesn't work
I just managed to crash my machine with it 
something oops'd within jbd2
i think the patch in the mailing list is designed for a later version of ext4 than that in the 2.6.28 kernel
as I had to fiddle around to get it to patch against 2.6.28
i think something I may have done in the fiddling to get it to work may have caused the problem
I'll try and hunt around for a version for 2.6.28
I think the ext4 maintaner would proabably perfer if kde fixed thay're fsync code
as at the moment it's relying on a bug / behaviour which is taken for granted within ext3
I think there's been a big discussion about it on some of the blogs
more info here http://suseunbound.lefora.com/2009/03/12/data-loss-may-occurr-when-using-ext4-and-kde-4/page1/
further Edit
couldn't find anyother source of the alloc_on_commit patch for earlier kernels
and I suspect they may be having problems with it anyway, oh well back to ext3 for me |
|
| Back to top |
|
|
shgadwa
Guru
Joined: 12 Mar 2009
Posts: 327
|
| Posted: Sun Mar 29, 2009 8:40 pm Post subject: |
|
|
Just a note:
I've installed Gentoo on EXT4.... no problem. It was quite easy to do. It did not work with the 2.6.27-gentoo-r8 kernel though. I did a bunch of research and concluded that for my computer, Zen-Sources would do me best. I've installed and configured the 2.6.29-rc7-zen1 Zen Sources Kernel, and I couldn't of been happier with the setup. EXT4 works great and so far I have not had any problems with my kernel, or the file system. |
|
| Back to top |
|
|
garlicbread
Apprentice
Joined: 06 Mar 2004
Posts: 182
|
| Posted: Sun Mar 29, 2009 11:36 pm Post subject: |
|
|
I think it all depends on which form of X windowing system your using
for general use ext4 should be fine, it just seems to be certain apps that don't implement fsync properly that could cause a problem
the only one I'm aware of is KDE4, which could result in data loss in the kde config files, as it's depending on behavior observed in ext3 which is technically classed as a bug |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Mar 30, 2009 9:21 am Post subject: |
|
|
| garlicbread wrote: | | for general use ext4 should be fine |
That's true, I also had no problems with it so far, although I use KDE.
| Quote: | | it just seems to be certain apps that don't implement fsync properly that could cause a problem |
Sorry, but I completely disagree: That's just a lame excuse of Ted Ts'o. Except for very exceptional purposes no program should ever have a reason to call fsync - just saving a new version of some existing file is certainly no such reason: Why should it be in the responsibility of the application to ensure that every single file it changes is saved to disk? This would undermine all the purpose of caching filesystems. (It would be different, if fsync() would not guarantee to write to disk but instead to set a barrier; however, such a "barrier()" command does not exist in POSIX).
It is the task of the filesystem to write the data to disk when it is appropriate and in such an order that it makes sense if a crash should occur: The filesystem receives the calls in the appropriate order and has to make sense from them - if it reorders the tasks for caching purposes, it (the filesystem code) is responsible that the reordering still is correct: Only the filesystem code has possibilities like setting barriers at the appropriate points etc. That also other filesystems fail to do this correctly is no real excuse. The alloc_on_commit strategy is probably the most correct solution (a real implementation of atomic operations would be more appropriate, but for this we have to wait for Reiser4 stabilization [which probably will never happen, unfortunately] or some unknown new filesystem). |
|
| Back to top |
|
|
garlicbread
Apprentice
Joined: 06 Mar 2004
Posts: 182
|
| Posted: Wed Apr 01, 2009 8:23 pm Post subject: |
|
|
Not to misunderstand I wasn't trying to point the finger and say it's an application issue, or it's a filesystem issue
only that the sofware affected by the issue appears to be limited to a select few apps such as kde4, wherever the fault may be
although it would be interesting to see if there was any low level console apps affected by this as well
to be honest I don't know enough about filesystems to say one way or the other
as near as I can tell part of the discussions seem to sit around the definition or meaning of fsync, or at least it's intended use
speaking generally, if an issue or change affects only one application and not multiple applications, then I'm more likley to be believe it's an issue specific to that application
If the issue affects multiple applications (e.g. older versions of KDE for example) then I'd be more likley to believe it's a filesystem issue
ideally you'd need more information as to which apps could be affected by the issue to say one way or the other (I have no idea)
As near as I can tell as a general rule of thumb
if you've been building a system just using a chroot and emerge at the command line, something that perhaps acts as a server then your probably fine
in my case since I will be using kde 4.2 it's just something I need to avoid untill it's all been straightened out by the kernel devs or the kde devs depending on your point of view
I was hopefull that the alloc_on_commit patch would have been a quick fix to the problem, even if it sacrificed performance
however after locking my machine with it, that's definitley right out for the time being at least |
|
| Back to top |
|
|
|
Documentation, Tips & Tricks
