http://permalink.gmane.org/gmane.comp.file-systems.xfs.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52716 <pre> It's more that you can't actually use for real power fail testing in xfstests. Keeping stuff in xfstests that the harness won't or can't ever use is just an added maintenance burden that we don't need. xfstests is not a dumping ground for random test source code that *might* be useful outside xfstests. Regression tests need to be as simple as possible so their functioning is obvious and easy to understand. There is nothing worse than a test failing and having to spend time determining if the test itself is failing or whether it's uncovered a real bug or not. And anytime I see a test with 500 lines of test infrasrtucture that can be replaced with a printf() call and some redirection in the test harness I see a test that is going to be trouble.... Sure, and now you want to put it in xfstests and the hwflush-check infrastructure is just too complex.... Cheers, Dave. </pre> Dave Chinner 2013-05-19T01:32:09 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52715 <pre> That's a corrupted freespace btree. Your only option at this point is to zero the log and hope that xfs_repair can clean everything up without too much loss. Damage has already been done, there's no way we can find the cause from the state you have on disk at this point, unfortunately. Cheers, Dave. </pre> Dave Chinner 2013-05-19T01:20:15 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52714 <pre> Hi Paolo, You've already contacted me off list about this and pointed me to this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1176977 which contains information that everyone looking at the problem should know. Also, any progress on testing the backported fix mentioned in the bug? You're testing swift benchmark which is probably a small file workload with large attributes attached. It's a good chance that the workload is fragmenting free space because swift is doing bad things to allocation patterns. It's almost certainly exacerbated by the tiny filesystem you are using (1.5GB), but you can probably work around this problem for now with allocsize=4096. I've got a fix that I'm testing for the underlying cause of the problem I'm aware of with this workload, but I'll need more information about your storage/filesystem config to confirm it is the same root cause first. Can you include the info from here: http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_pro</pre> Dave Chinner 2013-05-19T01:13:54 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52713 <pre> I'd recommend to let the Ubuntu 13.04 kernel settle for a while, Martin. </pre> Martin Spott 2013-05-18T19:56:09 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52712 <pre>Hello After upgrading my laptop from Ubuntu 12.04 LTS to Ubuntu 13.04 Raring i noticed that my Linux would not boot again. So after inserting Ubuntu 13.04 boot disk , this is what i've found out: ubuntu&lt; at &gt;ubuntu:~$ uname -a Linux ubuntu 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ubuntu&lt; at &gt;ubuntu:~$ sudo xfs_repair -v /dev/sda3 Phase 1 - find and verify superblock... - block cache size set to 363760 entries Phase 2 - using internal log - zero log... zero_log: head block 32468 tail block 31799 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. ubuntu&lt; at &gt;ubuntu:~$ ls /mnt/ ubuntu&lt; at &gt;ubuntu:~$ sudo mount /dev/sda3 /mnt ^C^C -&gt; moun</pre> Punk Rider 2013-05-18T18:39:19 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52711 <pre> This seemed to be worthy of early note: xfs/031 30s ...[ 587.843478] XFS (sdb6): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! [ 587.843478] Use of these features in this kernel is at your own risk! *** Error in `/sbin/mkfs.xfs': malloc(): smallbin double linked list corrupted: 0x0907f7d0 *** The test doesn't seem to finish, but Ctrl-c ends the test cleanly. No dmesg stuff is added, and strace doesn't show anything between the mount message and the error message. I'll need to re-enable tracers to provide a trace...and as traces can be huge, I'll wait on your advice. [BTW, the "30s" reference time is from the non-CRC run of your patched xfsprogs. The non-CRC run looked good.] Thanks! Michael _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Michael L. Semon 2013-05-18T18:13:21 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52710 <pre>In fact the reason is quite simple. Initially the this tool was designed for real disk cache testing under power failure conditions. And want to share it with community. Off course it is possible to simplify things for 'one hose' case but it is not too big. Let's review it one and keep it simple but useful not just for local but also for real power failure tests. Fairly to say that initial idea was to add persistent state to FIO. But logic starts to getting too complex so we write hwflush-check. _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Dmitry Monakhov 2013-05-18T12:13:25 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52709 <pre> Olá, Gostaríamos de convidar-lhe a conhecer o nosso trabalho. A Agência Triskel oferece serviço de criação de um site moderno para você ou para sua empresa. Pedimos que visite o nosso portfólio em nosso web site: http://www.triskelwebdesign.com &lt;http://www.triskelwebdesign.com/&gt; Poderá com isto verificar a qualidade do nosso trabalho. Criamos sites gerenciáveis, que você mesmo poderá administrar, atualizando e modificando as informações com grande facilidade. Criamos sites com a sua cara, o design é personalizado, sempre moderno e elegante, único, buscando atender e satisfazer os seus interesses. Por que a criação de um site é algo importante para você? Já passou o tempo em que web sites eram complicados e parte pequena do marketing de uma empresa. Com o crescimento substancial da internet, o marketing virtual tem se tornado imprescindível. Aumente suas chances de crescimento pessoal e profissional, invista em si mesmo e nos seus empreendimentos! Apresentamos algumas propos</pre> Juliana 2013-05-18T10:17:46 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52708 <pre>VM running via virtual box. The kernel is based on the updated xfs-next tree. root&lt; at &gt;linux32bit:/home/jeff# uname -a Linux linux32bit 3.10.0-rc1+ #1 SMP Sat May 18 15:30:11 CST 2013 i686 i686 i386 GNU/Linux Thanks, -Jeff _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Jeff Liu 2013-05-18T08:46:08 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52707 <pre> I tried to reproduce this issue against the latest upstream tree on 32-bit system but no luck. Could you please supply the following info: 1) xfs_db -r "-c freesp -s" /dev/sda5 2) xfs_info /mnt/sdb1 Thanks, -Jeff _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Jeff Liu 2013-05-18T08:43:47 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52706 <pre> Ah, excellent explanation! guilt sounds awesome. Not finding anything that looked like an official site for guilt that worked, I grabbed the guilt source from the wheezy section at packages.debian.org. At the next opportunity, I will learn it, live it, love it. Michael _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Michael L. Semon 2013-05-18T07:42:53 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52705 <pre> I read this and did not chime in because I don't know about the "no space left on device" error. The first issue the customer had, though, was one I had on a 2.8GHz Pentium 4. The idea of using a tunable to increase vmalloc space made me think, "What, am I using FreeBSD or something? Why didn't Linux auto-tune this?" so I dug deeper. [Disclaimer: I use FreeBSD and find value in it, but it requires at least some sysctl tuning for things that Linux will tune automatically.] Basically, I had vmalloc space to have an environment set up perfectly in 768 MB of RAM. Then I added another 512 MB, and Linux saw only 896 MB for lack of highmem support. At that point I enabled highmem support, Linux decided to auto-tune my vmalloc space down to 128 MB, which was not enough to handle an xfsdump of a 30 GB device-mapper crypt partition. The PC, when left alone, could develop those same oops-y messages while doing incremental xfsdumps overnight, and if left alone for days, even simple cp commands co</pre> Michael L. Semon 2013-05-18T06:27:19 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52704 <pre>.... It shouldn't. .... Thanks, i'll have a look at them on monday... Being able to add and remove patches and reorder them easily is exactly why I use guilt. The raw git workflow is, well, less than optimal IMO. So, once I've have a patch series imported into git as a guilt stack, it's managed as a series of patches rather than as individual patches or commits. The order is kept in a series file. So, updating the underlying release for a specific patch set is effectively: $ guilt checkout working# go to base tree branch $ guilt pop -a# remove all patches in the branch $ git reset --hard v3.10-rc1# reset branch to known clean state $ git remote update $ git merge origin/master# linus tree $ git merge xfs-oss/master# xfs tree $ guilt push -a# push all local patches back into branch At this point I have an up-to-date linus + xfs + local patches branch. Say now I want add a new patchset in from the list. I save it as an mbox file "saved-patches". Then I create a new branch from the xfs tree</pre> Dave Chinner 2013-05-18T06:27:19 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52703 <pre> If it makes any difference at all, I'm saving these patches using Thunderbird... The pre-patchset xfsprogs has been saved as a tarball, so I can provide a non-git patch session if necessary. Sorry so vague last time: I was overjoyed that everything went through git so cleanly. This is the result of the patches about which `git am` complained: PATCH 08: Applying: libxfs: add support for crc headers on remote symlinks /usr/src/xfs/xfsprogs/.git/rebase-apply/patch:282: new blank line at EOF. + PATCH 14: Applying: xfs: add CRCs to dir2/da node blocks /usr/src/xfs/xfsprogs/.git/rebase-apply/patch:61: trailing whitespace. nodehdr.level, id-&gt;ino, warning: 1 line adds whitespace errors. PATCH 16: Applying: xfs: split remote attribute code out /usr/src/xfs/xfsprogs/.git/rebase-apply/patch:722: new blank line at EOF. + warning: 1 line adds whitespace errors. PATCH 17: Applying: xfs: add CRC protection to remote attributes /usr/src/xfs/xfsprogs/.git/rebase-apply/</pre> Michael L. Semon 2013-05-18T05:40:39 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52702 <pre> No, #jeffpc is Josef Sipek. Author of guilt and many other useful things. Sounds good to me ;) Cheers, Dave. </pre> Dave Chinner 2013-05-18T05:39:36 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52701 <pre>Ah? #jeffpc == me ? #jeffpc is up and listening... : just ignore; Looks our test for 32-bit system is insufficient. There has another bug reports regarding 32-bit yesterday: http://oss.sgi.com/archives/xfs/2013-05/msg00494.html So I'm going to setup a 32-bit test environment for such tests together with Michael. Thanks, -Jeff _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Jeff Liu 2013-05-18T05:07:28 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52700 <pre> Can you send me the output indicating where the whitespace errors are? I don't get any warnings from guilt about them when I apply the patchset here... Not surprising - I haven't got a crc enabled filesystem all the way through xfstests yet. remote attributes are the current piece I'm working on getting fixed. And reporting bugs :) How are you managing patches right now? When taking in a new patchset from a mailing list, I save them all in a mbox file, then use git-am to apply them to a temporary git branch. I then move to my real working branch, and do a 'guilt import-commit x..y' to convert the commits in the temporary branch to a set of guilt patches, and then go from there.... The worst step for me is, by far, the git-am step. Resolving patch conflicts is painful because you have to manually apply the patch, then remember to git add all the files modified by the patch, etc. It'd be really cool if guilt could do the import directly from the mbox file without applying the patches, so the normal gu</pre> Dave Chinner 2013-05-18T03:25:07 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52699 <pre> Hi Josh - For starters, have you engaged your RH support folks? Which one? RH support can probably help you decide if that bug report applies, and where/when it was fixed. shouldn't be because they had all been properly synced to disk before the power loss, or? (just in general, files not fsynced aren't guaranteed to be in any particular state if you lose power, though of course there are certain expectations of timely flushing). If you have backups that's probably the best option. -Eric p.s. xfs_check is deprecated in favor of xfs_repair [-n] _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Eric Sandeen 2013-05-17T21:44:07 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52698 <pre>Hi Dave, On Fri, May 17, 2013 at 11:10:24AM +1000, Dave Chinner wrote: I'll take a look, thanks. -Ben _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Ben Myers 2013-05-17T21:43:28 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52697 <pre> &lt;snip&gt; Jeff, "if else" construct is preferred for readability than "? :" construct. So, I am leaving it as is. &lt;snip&gt; _______________________________________________ xfs mailing list xfs&lt; at &gt;oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs </pre> Chandra Seetharaman 2013-05-17T21:15:44 http://permalink.gmane.org/gmane.comp.file-systems.xfs.general/52696 <pre> OK. The basics look good so far. The patchset applied without need for additional work with vi and patch. Whitespace errors were reported for Patches 8, 14, 16, 17, 24, 25, and 27. xfsprogs built with no additional errors over a normal xfsprogs build. That all stated, the `tar -xvf qt-source.tar.xz` still fails on a CRC-enabled filesystem. Worse, until I return home, I won't be able to do serial-console capture of hard oopses. However, the initial oops I got was a soft one, so it is included after my closing. The kernel is this... last night's kernel git last night's xfs-oss/master some of your recent patches (didn't apply your 6_5 patch yet) J. Liu's most recent patchset + 2 older bitness patches Chandra's v8 pquota/gquota patchset + one E-mail fix Shaggy's JFS patch to make it through the old xfstests #068 on JFS an NILFS2 patch to address broken bmap handling, lurked from the NILFS2 mailing list one local removed assert to make it through the old xfstests #111 maybe one or two XF</pre> Michael L. Semon 2013-05-17T20:54:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.file-systems.xfs.general