Re: XFS In Dapper [previously posted to ubuntu-users]
Michael Hipp [EMAIL PROTECTED] writes: David Kempe wrote: Nick Webb wrote: I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). Er, that fsck is for the sake of safety and can be disabled; feel free to do so and take the same risks that XFS exposes you to. If that is your /only/ reason for preferring XFS then worry no more. (See tune2fs for details; set the mount count and time for fsck to off) The file system will also likely have many large files, so XFS seems to be a good choice for this as well. The benefits may be more mixed than you expect, unless you need good streaming write performance for those files. Importantly, you can have data-loss on XFS if you lose power suddenly, perhaps more so than ext3. When files get corrupted on XFS, I have noticed they go to zero size, That is very odd. XFS, up until the version in 2.6.24 (the Hardy kernel) had a combination of choices about security and performance that would result in file content replaced by NULL in some cases.[1] None of these would result in zero size files. whereas in messy situations with ext3 I have noticed you are more likely to loose metadata than data. I still would stick with XFS anyday though, even just because the sheer increase in format time. Heh. Formatting 1.4TB of ext3 today was certainly an exercise in patience. :) I've experienced this data loss on XFS more than once due to one kind of abrupt shutdown or another. XFS seems fragile. Almost like it's not a journaled filesystem at all. I wouldn't use XFS on a machine where power loss was possible before 2.6.24, but wouldn't hesitate to recommend it at or after that point. (In other words: not for a month or so, and not unless you want to run the new software the first day.) XFS has several advantages over ext3. But I abandoned it because of this fragility. Ext3 seems far more idiot proof and I prefer things that just work even if they're not glamorous. I agree: for a long time I wouldn't use XFS for much the same reason. The applications that fail are poorly written and will lose or corrupt data in plenty of other circumstances, sure[2], but I would rather cope than lose data I care about.[3] Thankfully that has been changed by the upstream XFS team, so I am much happier now. Regards, Daniel Footnotes: [1] These are poorly written applications; the situation was that truncate would record the size change but not flush data to disk, risking data exposure, resulting in the security decision to expose only NULL bytes to the user.[4] [2] Hi, older sendmail, I am looking at your map utilities indeed. [3] Well, I actually keep data I care about well away from them, but enough of them are convenient that... [4] ext3 made the opposite choice: to risk exposing potentially security related (or otherwise undesirable) content in a file that was treated that way, in return for preserving whatever content was written successfully. -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On 3/6/08, Daniel Pittman [EMAIL PROTECTED] wrote: Michael Hipp [EMAIL PROTECTED] writes: Oliver Brakmann wrote: On Wed, 2008-03-05 17:04, David Kempe wrote... Importantly, you can have data-loss on XFS if you lose power suddenly, perhaps more so than ext3. When files get corrupted on XFS, I have noticed they go to zero size I believe I read somewhere that that has been fixed some time ago. Oliver, could you perchance find a reference for that? Dapper really isn't that old. The change was in 2.6.24, so will be in Hardy, but is not present in any file system before that. There were some data corruption bugs around 2.6.17, none of which were ever in an Ubuntu release that I am aware of, and which have since been fixed; these are unlikely to be what the posters here are describing.[1] Not disagreeing. I'd *like* to use XFS, I just feel burned by it. An indicator that this issue has been solidly addressed would be great news. It should be more or less as solid as writeback ext3 now, but less safe than data journaled ext3. Some things to read: http://www.debian-administration.org/articles/388#comment_40 (read all comments to the end) This comment, and the few subsequent, are a misunderstanding of how things work. The problem illustrated is not that enterprise applications do their own data recovery. The problem is that POSIX file semantics make some things safe and some things dangerous regarding your files. The applications that see NULL content would probably be corrupt on disk, since they have changed their size and (potentially) appended random data to the end of their content. The sad part is that most application developers don't really understand POSIX I/O semantics and, so, many popular applications are vulnerable to this. (hint for those at home: write your content to a new file and rename it over the existing one; this is atomic, assuring you that the new or the old file is there, nothing in between. for bonus points include some recovery to determine if the new version is complete and coherent, then offer to complete the task.) http://www.tummy.com/journals/entries/jafo_20041226_015752 For a user who claims to care about data integrity this poster seems to have little actual clue: JFS is an exciting choice, at best, and reiserfs... Well, hey, the point someone starts talking about using reiserfs and data integrity being important to them you can more or less know they don't really understand how data integrity is achieved. reiserfs (3) has significant issues, many of which are performance or data integrity related, and is close to impossible to recover if /anything/ goes wrong.[2] Regards, Daniel Footnotes: [1] Their symptoms were completely different, much nastier, and fairly identifiable. Zero length or null-filled files were not among them. [2] ...or you happen to store anything that looks like a reiserfs filesystem inside them when you run the fsck tools.[3] [3] This is highly amusing to me as I recall the excitement when the developers announced a library version of reiserfs intended as a compound document format for applications to use, delivering the same performance as the file system they were stored in... -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam Hey, Thought I'd share my experiences with reiserfs... I'm using reiserfs on my mythtv box with a 4x400GB software raid5 array (~1.2TB usable) and it has been ok, but also unstressed so I won't go as far as vouching for it in a production environment. It's strength seems to lie in large numbers of small files rather than the large audio/video you're using. On the recovery side though, I was fiddling with the underlying lvm md and managed to bork the system. I rebuilt the whole thing with the exact same parameters as I used originally and ran the reiserfs recovery tool to find it pulling files out of my (reiserfs formatted) VM images as well as the files actually in the fs. I ended up getting back _most_ of my data and had backups of the vms, so it wasn't a complete loss. I think the tried and tested 'just works' of ext3 would probably be a better choice in a potential recovery situation. My new place has brown outs during almost every storm and I've yet to invest in a UPS, the system has so far come back up without issue. cheers, Owen. -- If it aint broke, fix it 'till it is. -- -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On Tue, Mar 04, 2008 at 09:21:07PM -0800, Nick Webb wrote: Hi All - I posted this question to the ubuntu-users list perviously, but this seems like the proper list to post to (I just discovered this list). I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). The file system will also likely have many large files, so XFS seems to be a good choice for this as well. Can anyone share their XFS experiences on Ubuntu Dapper? Is it as stable as ext3 in your experience? Any tips/tricks/gotchas? Any other file systems I should look at (JFS, ReiserFS, etc.)? I posed the same question to other Linux users I know, and there was a mix of I've had no problems to I stuck with ext3, it's solid and I know I can trust it, despite the horrible fsck times. I'm really curious to get other opinions, especially with the shipped binaries on Dapper, as we only use LTS for production machines. Thanks! Nick -- Nick Webb System Administrator Freelock Computing - www.freelock.com 206.577.0540 x22 -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On Tue, Mar 4, 2008 at 11:21 PM, Nick Webb [EMAIL PROTECTED] wrote: Can anyone share their XFS experiences on Ubuntu Dapper? Is it as stable as ext3 in your experience? Any tips/tricks/gotchas? Any other file systems I should look at (JFS, ReiserFS, etc.)? I have a (comparatively small) 1TB filesystem on top of a RAID5 attached to a server that has evolved through Dapper-Edgy-Feisty-Gutsy. Before settling on XFS, I ran a few benchmarks testing EXT3, JFS, and XFS. EXT3 reduced my overall formatted partition most drastically (which is a lot of Gig's thrown away on huge filesystems). I also found huge differences between XFS/JFS and EXT3 on file deletes. I have had no problems to speak of with XFS. Finally, you might find this article informative: http://www.debian-administration.org/articles/388 :-Dustin -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On Wed, Mar 05, 2008 at 08:35:07PM +, Adam McGreggor wrote: What I meant to say was... On Tue, Mar 04, 2008 at 09:21:07PM -0800, Nick Webb wrote: Hi All - I posted this question to the ubuntu-users list perviously, but this seems like the proper list to post to (I just discovered this list). I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). The file system will also likely have many large files, so XFS seems to be a good choice for this as well. (just as a suggestion): perhaps disable fsck at bootime, via tune2fs ? -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
David Kempe wrote: Nick Webb wrote: I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). The file system will also likely have many large files, so XFS seems to be a good choice for this as well. Importantly, you can have data-loss on XFS if you lose power suddenly, perhaps more so than ext3. When files get corrupted on XFS, I have noticed they go to zero size, whereas in messy situations with ext3 I have noticed you are more likely to loose metadata than data. I still would stick with XFS anyday though, even just because the sheer increase in format time. I've experienced this data loss on XFS more than once due to one kind of abrupt shutdown or another. XFS seems fragile. Almost like it's not a journaled filesystem at all. XFS has several advantages over ext3. But I abandoned it because of this fragility. Ext3 seems far more idiot proof and I prefer things that just work even if they're not glamorous. Just my experiences. Michael -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
Adam McGreggor wrote: On Wed, Mar 05, 2008 at 08:35:07PM +, Adam McGreggor wrote: What I meant to say was... On Tue, Mar 04, 2008 at 09:21:07PM -0800, Nick Webb wrote: Hi All - I posted this question to the ubuntu-users list perviously, but this seems like the proper list to post to (I just discovered this list). I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). The file system will also likely have many large files, so XFS seems to be a good choice for this as well. (just as a suggestion): perhaps disable fsck at bootime, via tune2fs ? Yeah, I've had this thought. I do this even on 1TB ext3 file systems, just so I don't get caught in the awkward, yeah it will be up in 15 minutes which turns into 2 hours situation. However, is it really safe to never do an fsck? It seems that most of the time it's unnecessary for ext3 as the journal recovery usually works fine. The tune2fs man page also states this, which I could just ignore, but makes me feel slightly uneasy: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesys‐ tem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. Perhaps the right answer is to do regular maintenance once or twice a year on these huge filesystems. In most cases I can find 8hours or more to schedule an fsck on a Friday night... Nick -- Nick Webb System Administrator Freelock Computing - www.freelock.com 206.577.0540 x22 -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On 06/03/08 06:09, Nick Webb wrote: Adam McGreggor wrote: On Wed, Mar 05, 2008 at 08:35:07PM +, Adam McGreggor wrote: What I meant to say was... On Tue, Mar 04, 2008 at 09:21:07PM -0800, Nick Webb wrote: Hi All - I posted this question to the ubuntu-users list perviously, but this seems like the proper list to post to (I just discovered this list). I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). The file system will also likely have many large files, so XFS seems to be a good choice for this as well. (just as a suggestion): perhaps disable fsck at bootime, via tune2fs ? Yeah, I've had this thought. I do this even on 1TB ext3 file systems, just so I don't get caught in the awkward, yeah it will be up in 15 minutes which turns into 2 hours situation. However, is it really safe to never do an fsck? It seems that most of the time it's unnecessary for ext3 as the journal recovery usually works fine. The tune2fs man page also states this, which I could just ignore, but makes me feel slightly uneasy: You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesys‐ tem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point. Perhaps the right answer is to do regular maintenance once or twice a year on these huge filesystems. In most cases I can find 8hours or more to schedule an fsck on a Friday night... Nick I have personal experience where EXT3 still requires an fsck to stop data loss. It shouldn't happen, but on occasion it does. -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On 05/03/08 14:21, Nick Webb wrote: Hi All - I posted this question to the ubuntu-users list perviously, but this seems like the proper list to post to (I just discovered this list). I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). The file system will also likely have many large files, so XFS seems to be a good choice for this as well. Can anyone share their XFS experiences on Ubuntu Dapper? Is it as stable as ext3 in your experience? Any tips/tricks/gotchas? Any other file systems I should look at (JFS, ReiserFS, etc.)? I posed the same question to other Linux users I know, and there was a mix of I've had no problems to I stuck with ext3, it's solid and I know I can trust it, despite the horrible fsck times. I'm really curious to get other opinions, especially with the shipped binaries on Dapper, as we only use LTS for production machines. Thanks! Nick I've read many of the responses you received and I wondered something else. I don't know what kind of data set you have that requires 2TB partitions, but another route to travel would be multiple smaller partitions that you each check on a regular basis. Unmount the partition, fsck it, then remount it. -- Onno Benschop Connected via Optus B3 at S31°54'06 - E115°50'39 (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On Wed, 2008-03-05 17:04, David Kempe wrote... XFS is good, we use it on dapper all the time. My largest XFS filesystem is 5.5TB formatted. While I don't have such huge filesystems, I've been using XFS for ~6 years now, without any problems at all. btw, one thing I found was that xfs_repair can chew massive amounts of ram to run a repair on a filesystem. I had a 2TB fs take nearly 8gb of ram (and swap) to repair it. It did a good job of repairing, and took ages. They're actually working on fixing that. See this interesting talk: http://linux.conf.au/programme/detail?TalkID=135 Slides: http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf Video: http://mirror.linux.org.au/pub/linux.conf.au/2008/Wed/mel8-135.ogg Importantly, you can have data-loss on XFS if you lose power suddenly, perhaps more so than ext3. When files get corrupted on XFS, I have noticed they go to zero size I believe I read somewhere that that has been fixed some time ago. Oliver -- Sometimes an impulsive 2:00 AM cross-country trip is the only solution. - http://xkcd.com/352/ NP: Dream Theater - Octavarium -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
On 05/03/2008, Michael Hipp [EMAIL PROTECTED] wrote: I've experienced this data loss on XFS more than once due to one kind of abrupt shutdown or another. XFS seems fragile. Almost like it's not a journaled filesystem at all. It's an enterprise FS from big iron country. It - and JFS - were designed in the expectation that they would at all times be run on a machine protected by a UPS with automatic shutdown, because that's just what you /do/ with big corporate servers. It's not even a question. Alas, it's *not* a given in Linux-land... -- Liam Proven • Profile: http://www.linkedin.com/in/liamproven Email: [EMAIL PROTECTED] • GMail/GoogleTalk/Orkut: [EMAIL PROTECTED] Tel: +44 20-8685-0498 • Cell: +44 7939-087884 • Fax: + 44 870-9151419 AOL/AIM/iChat: [EMAIL PROTECTED] • MSN/Messenger: [EMAIL PROTECTED] Yahoo: [EMAIL PROTECTED] • Skype: liamproven • ICQ: 73187508 -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: XFS In Dapper [previously posted to ubuntu-users]
Nick Webb wrote: I've got a couple projects coming up that will have a file systems = 2TB and I'm thinking of using XFS for it. Main feature of XFS I need is the lack of fsck at startup (fsck for ext2/3 will take many hours with a 2TB partition). The file system will also likely have many large files, so XFS seems to be a good choice for this as well. XFS is good, we use it on dapper all the time. My largest XFS filesystem is 5.5TB formatted. I have to say 64-bit is the only way to go for this - the xfs repair tools can't handle larger filesystems in 32bit mode. btw, one thing I found was that xfs_repair can chew massive amounts of ram to run a repair on a filesystem. I had a 2TB fs take nearly 8gb of ram (and swap) to repair it. It did a good job of repairing, and took ages. So XFS is not free of the fsck problem, just xfs_check is faster and perhaps less thorough (dunno). Importantly, you can have data-loss on XFS if you lose power suddenly, perhaps more so than ext3. When files get corrupted on XFS, I have noticed they go to zero size, whereas in messy situations with ext3 I have noticed you are more likely to loose metadata than data. I still would stick with XFS anyday though, even just because the sheer increase in format time. I have had good results on many different types of block devices as well. thanks dave -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
