similar to: chown/quota bug in ext3

dear smbfs maintainers! i sent this mail to you, since i got no answer from sending it to the "M:" entry of SMBFS. _______________ i had problems with setting permissions on a mounted smb file system. therefore i took a look at the smbfs code and a suspicious code part caught my eye. IMHO the patched line can't be correct, because comparing uids to gids doesn't make any sense.

Hello, the following series of patches fixes some issues with OCFS2 quotas. The first patch modifies VFS quota locking, the next patch uses the fact to simplify OCFS2 quota locking and solves a few deadlock issues. The third and the fourth patches fix another possible deadlocks in OCFS2 quota code and the last patch is a minor cleanup. Honza

Hi, the first four patches in this series fix locking problems in OCFS2 quota code (three of them can lead to potential deadlocks). The fifth patch reorders ip_alloc_sem for directories to be acquired before localalloc locks. Mark would you please merge these? The last two patches implement lockdep annotations for OCFS2 cluster locks. We annotate all the cluster locks except for special ones

Hi, A system running ext3 crashed this afternoon (nothing to do with ext3, bad network driver). Is was saving a file from emacs when it happened. The file system is 0.06b and had ordered data as the mount option. Let me emphasize this was running ext3 pure, not with SnapFS or InterMezzo layered on top of it. strace reveals that Emacs does open("existing file name", O_TRUNC |

Hi, I'm resending this patch series. It's rediffed against linux-next branch of Joel's git tree. The first four patches are obvious fixes of deadlocks in quota code and should go in as soon as possible. The other three patches implement lockdep support for OCFS2 cluster locks. So you can have a look whether the code make sence to you and possibly merge them. They should be NOP when

Has anyone tried LFS (ie >2G files support) and Ext3 together? Are there good reasons why this should/should not work? I see the RH enterprise kernel patch set specifically does not attempt both lfs and ext3, but the lfs patches themselves touch some reasonably localised parts of ext2, so I would hope (without having dived in there to test), that the ext3 changes would mirror that

i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it''s use case in the core direct I/O code is more like a counter given that the writers already have external serialization. This series removes it in favour of a simpler counter scheme, thus getting rid

Hi, When trying to run a particular program, I reproducibly get a few dozen kernel messages of the form: attempt to access beyond end of device 03:06: rw=0, want=536995844, limit=11680168 attempt to access beyond end of device 03:06: rw=0, want=1342296068, limit=11680168

Assertion failure in journal_add_journal_head() at fs/jbd/journal.c:1679 : "(((&bh->b_count)->counter) > 0) || (bh->b_page && bh->b_page->mapping)" ------------[ cut here ]------------ kernel BUG at fs/jbd/journal.c:1679! invalid operand: 0000 [#2] CPU: 0 EIP: 0060:[<c017637f>] Not tainted EFLAGS: 00010282 EIP is at

Hi! I tried to use cdrdao on 2.5.5x kernels but kernel gives me following messages. Further debugging reveals that sb is NULL in __ext3_std_error() function. I tried this on ext2 and it seems it isn't ext3 specific, on ext2 it also doesn't work. cdrdao is after this in D state and is unkillable, but the CD-ROM drive from which I tried to grab is perfectly usable. This happens to me

Hello all: I was getting a reproducible crash during an update of a xen system. The problem went away after I set SELinux to permissive, but the fact that it crashed was alarming (first one on a non-dev system that I've had in over a year). I attempted the update earlier but it crashed at the same point after attempting to update selinux. After verifying hardware (all clean) I ran it again

Several times recently my "mutt" email program has looped for hours at a time in the middle of a sys_ftruncate call. This happens when I use the "$" command to write changes out to my mailbox. It does eventually return from the call and everything seems to have worked ok. But in the meantime the CPU is pegged, $MAIL is locked so I can't receive new mail, and signals to

https://bugzilla.samba.org/show_bug.cgi?id=10295 Summary: do_lchown() after set_xattr() causes xattrs to be dropped on Linux 3.10.20. Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at

Hello, We have about 20 - 30 embedded machines running Linux 2.4.13, which the ext3-2.4-0.9.13-2413 patch applied. These are PowerPC 7410 based systems. I am getting reports of Oops happening either during removes (rm's), or coppies (cp's). Most reports state that issuing the same command once the system boots back up, does not cause it to crash. I guess its something else leading up

In August I reported a problem with the sys_ftruncate call that caused me to reboot my machine. I didn't see any responses to it then on the ext3 list, and the problem is now recurring, so I thought I'd try again. I don't think I've rebooted since the last problem. In the last few days it hasn't taken as long as 17 hours, but it has sometimes taken unusual and uncomfortable

Hi, I use ext3 over RAID1+0 LUN. When I disconnect my fiber cable to the RAID (in order to force a migration to a failover node) I expect to see I/O errors and then a failure to write/read to the filesystem, but in addition I get an Assertion failure. The end result is of course an unusable system which needs to be rebooted. (I reboot the system via machine_restart which works okay but I guess

Hello Since 2.4.20, we have problems with ext3. Machine is 2xPentium III (1GHz), 2GB RAM, 1GB swap. RH 8.0 (glibc-2.3.1-21), gcc (GCC) 3.2 20020903 We have a lot of users: oceanic:~# wc -l /etc/passwd 6694 /etc/passwd connected via SAMBA (2.2.7) from 200-300 Windows-XX workstations Partition with ext3 looks like this: oceanic:~# mount |grep ext3 /dev/sdb5 on /home1 type ext3

I got this.. The system was usuable, but not very. If I tried to access the ext3 volume, it would hang. Reboot hung too, complaining about too many open files. Any ideas? I have no idea what triggered it; this is a big file/web/mail server, with all of that on the ext3 volume. And I've never run ksymoops before, but I think I did it right. - Josh Assertion failure in

Am 27.06.2000 19:58:44 schrieb urban: > On Tue, 27 Jun 2000 klaus-georg.adams@rwg.de wrote: > > > > > Hi Andrew, > > your patch from 2.2.15 to 2.2.16, backing out the older protocol levels breaks > > reading from an OS/2 LAN Server. > > The appended patch fixes things for me (against 2.2.16). > > This backs out a lot of desired changes. For example I think

Hi, I got the same problem as Juergen, My volume is a simple replicated volume with 2 host and GlusterFS 3.2.0 Volume Name: poolsave Type: Replicate Status: Started Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: ylal2950:/soft/gluster-data Brick2: ylal2960:/soft/gluster-data Options Reconfigured: diagnostics.brick-log-level: DEBUG network.ping-timeout: 20 performance.cache-size: 512MB