FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 02-16-2012, 08:35 PM
Mike Snitzer
 
Default

On Thu, Feb 16 2012 at 4:25pm -0500,
Mike Christie <michaelc@cs.wisc.edu> wrote:

> On 02/16/2012 03:03 PM, Mike Snitzer wrote:
> > On Thu, Feb 16 2012 at 3:02pm -0500,
> > Mike Snitzer <snitzer@redhat.com> wrote:
> >
> >> FYI, I'll bounce a message detailing the iSCSI scatter-gather NULL
> >> pointer I _always_ hit with dm-io issuing async WRITE_SAME.
> >
> > I developed a patch for dm-io so that the new dm-thinp target can
> > leverage your new WRITE SAME functionality for, hopefully, more
> > efficient zeroing of the disk (see: dm-io-WRITE_SAME.patch at the end of
> > the following patchset).
> >
> > Here is the patchset I'm using ontop of Linux 3.2:
> > http://people.redhat.com/msnitzer/patches/upstream/dm-io-WRITE_SAME/series.html
> >
> > All works great on FC (tested against NetApp 3040 LUN)... I'm using the
> > thinp-test-suite to test dm-thinp's use of dm_kcopyd_zero().
> >
> > But testing with iSCSI, I get a NULL pointer _every_ time in the iSCSI
> > scatter-gather code, see:
> > http://people.redhat.com/msnitzer/patches/upstream/dm-io-WRITE_SAME/async-WRITE_SAME-makes-iscsi-sg-die.txt
> > -- in the middle of that file you'll see my 'crash' analysis of the
> > issue -- but that is just the NULL pointer.. no idea what the smoking
> > gun is that caused the iscsi_segment to become NULL.
> >
> > Anyway, taking a step back... WRITE SAME is all about transfering a
> > single logical block, backed by a single empty_zero_page in this test
> > case, so I'm wondering if for some reason iSCSI's sg code is getting
> > confused and thinking that more pages need to be transferred than were
> > in the original bio's payload (but iSCSI is way beneath the bio -> SCSI
> > command translation... grr)
>
> Yeah, probably a request/scsi_cmnd/sg sector/length/offset value is off
> or iscsi is making a bad assumption.
>
> Do:
>
> echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_session
> echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_session
> echo 1 > /sys/module/libiscsi_tcp/parameters/debug_libiscsi_tcp
> echo 1 > /sys/module/libiscsi_tcp/parameters/iscsi_tcp
>
> then rerun your test.

OK, will retry with all 4.. but just this caused the system to crap
itself:

echo 1 > /sys/module/libiscsi_tcp/parameters/debug_libiscsi_tcp

(I did this to turn on the ISCSI_DBG_TCP messages I noticed while
reviewing the code).

I saw a bunch of opcode 0x25 (READ CAPACITY) but never did see 0x93
(WRITE_SAME_16) come through.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-16-2012, 10:50 PM
"David C. Rankin"
 
Default

On 02/13/2012 04:55 PM, David C. Rankin wrote:
> On 02/13/2012 04:39 PM, Tom Gundersen wrote:
>> On Mon, Feb 13, 2012 at 10:55 PM, Calvin Morrison
>> <mutantturkey@gmail.com> wrote:
>>> es with this before as well. Do you have an exact
>>> error? Mine ended up being a udev rule written by hal that caused the
>>> breakage. Hopefully we can get it resolved.
>>
>> Does HAL still write the offending rule on updated systems? If so,
>> could you paste it so we can see how big trouble to expect?
>>
>> HAL was already dead when I got involved with these things, so please
>> forgive my ignorance.
>>
>> -t
>>
>
> Tom, Calvin,
>
> Thanks. Calvin, which rule? I probably is udev. You think Soltys can find it
> in AUR version and get rid of it?
>

The boot hang was cause by the move of udev binaries from /sbin to /usr/bin. hal
had hard-coded the /sbin location. Pawel updated the hal package in AUR and it
solved the problem. If your system is using hal in any way, then update to hal
0.5.14-8:

https://aur.archlinux.org/packages.php?ID=51454

--
David C. Rankin, J.D.,P.E.
 
Old 02-17-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 14 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 16 packages missing signoffs
* 2 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [community-testing] in last 24 hours (14 total) ==

* hostapd-0.7.3-6 (i686)
* ipvsadm-1.26-2 (i686)
* keepalived-1.2.2-3 (i686)
* knemo-0.7.3-2 (i686)
* libvirt-0.9.10-1 (i686)
* netcf-0.1.7-3 (i686)
* simh-3.8.1-3 (i686)
* hostapd-0.7.3-6 (x86_64)
* ipvsadm-1.26-2 (x86_64)
* keepalived-1.2.2-3 (x86_64)
* knemo-0.7.3-2 (x86_64)
* libvirt-0.9.10-1 (x86_64)
* netcf-0.1.7-3 (x86_64)
* simh-3.8.1-3 (x86_64)


== Incomplete signoffs for [community] (16 total) ==

* dbmail-3.0.0_rc3-1 (i686)
0/2 signoffs
* hostapd-0.7.3-6 (i686)
0/2 signoffs
* ipvsadm-1.26-2 (i686)
0/2 signoffs
* keepalived-1.2.2-3 (i686)
0/2 signoffs
* knemo-0.7.3-2 (i686)
0/2 signoffs
* libvirt-0.9.10-1 (i686)
0/2 signoffs
* netcf-0.1.7-3 (i686)
0/2 signoffs
* simh-3.8.1-3 (i686)
0/2 signoffs
* dbmail-3.0.0_rc3-1 (x86_64)
0/2 signoffs
* hostapd-0.7.3-6 (x86_64)
0/2 signoffs
* ipvsadm-1.26-2 (x86_64)
0/2 signoffs
* keepalived-1.2.2-3 (x86_64)
0/2 signoffs
* knemo-0.7.3-2 (x86_64)
0/2 signoffs
* libvirt-0.9.10-1 (x86_64)
0/2 signoffs
* netcf-0.1.7-3 (x86_64)
0/2 signoffs
* simh-3.8.1-3 (x86_64)
0/2 signoffs


== All packages in [community-testing] for more than 14 days (2 total) ==

* dbmail-3.0.0_rc3-1 (i686), since 2012-01-15
* dbmail-3.0.0_rc3-1 (x86_64), since 2012-01-16


== Top five in signoffs in last 24 hours ==

1. eric - 6 signoffs
2. thomas - 4 signoffs
3. dan - 4 signoffs
4. tpowa - 4 signoffs
5. allan - 3 signoffs
 
Old 02-17-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 27 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 2 fully signed off packages
* 143 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (27 total) ==

* crda-1.1.2-2 (i686)
* iw-3.3-2 (i686)
* libnl-3.2.7-1 (i686)
* libpcap-1.2.1-2 (i686)
* linux-lts-3.0.21-2 (i686)
* wpa_supplicant-0.7.3-5 (i686)
* crda-1.1.2-2 (x86_64)
* iw-3.3-2 (x86_64)
* libnl-3.2.7-1 (x86_64)
* libpcap-1.2.1-2 (x86_64)
* linux-lts-3.0.21-2 (x86_64)
* wpa_supplicant-0.7.3-5 (x86_64)
* bluez-4.98-3 (i686)
* kismet-2011_03_R2-4 (i686)
* net-snmp-5.7.1-2 (i686)
* networkmanager-0.9.2.0-2 (i686)
* ntrack-1:16-2 (i686)
* ruby-1.9.3_p125-1 (i686)
* bluez-4.98-3 (x86_64)
* kismet-2011_03_R2-4 (x86_64)
* net-snmp-5.7.1-2 (x86_64)
* networkmanager-0.9.2.0-2 (x86_64)
* ntrack-1:16-2 (x86_64)
* ruby-1.9.3_p125-1 (x86_64)
* ruby-docs-1.9.3_p125-1 (any)
* libnl1-1.1-1 (i686)
* libnl1-1.1-1 (x86_64)


== Incomplete signoffs for [core] (12 total) ==

* crda-1.1.2-2 (i686)
0/2 signoffs
* iw-3.3-2 (i686)
0/2 signoffs
* libnl-3.2.7-1 (i686)
0/2 signoffs
* libpcap-1.2.1-2 (i686)
0/2 signoffs
* linux-lts-3.0.21-2 (i686)
0/2 signoffs
* wpa_supplicant-0.7.3-5 (i686)
0/2 signoffs
* crda-1.1.2-2 (x86_64)
0/2 signoffs
* iw-3.3-2 (x86_64)
0/2 signoffs
* libnl-3.2.7-1 (x86_64)
0/2 signoffs
* libpcap-1.2.1-2 (x86_64)
0/2 signoffs
* linux-lts-3.0.21-2 (x86_64)
1/2 signoffs
* wpa_supplicant-0.7.3-5 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (128 total) ==

* glproto-1.4.15-1 (any)
1/2 signoffs
* inputproto-2.1.99.6-1 (any)
1/2 signoffs
* libreoffice-i18n-3.5.0-1 (any)
0/2 signoffs
* namcap-3.2.2-1 (any)
1/2 signoffs
* xcb-proto-1.7-2 (any)
0/2 signoffs
* bluez-4.98-3 (i686)
0/2 signoffs
* kismet-2011_03_R2-4 (i686)
0/2 signoffs
* libpciaccess-0.12.902-1 (i686)
0/2 signoffs
* libreoffice-3.5.0-1 (i686)
0/2 signoffs
* libx11-1.4.99.1-1 (i686)
0/2 signoffs
* libxcb-1.8-2 (i686)
0/2 signoffs
* libxi-1.5.99.3-1 (i686)
0/2 signoffs
* mesa-8.0-1 (i686)
0/2 signoffs
* net-snmp-5.7.1-2 (i686)
0/2 signoffs
* networkmanager-0.9.2.0-2 (i686)
0/2 signoffs
* ntrack-1:16-2 (i686)
0/2 signoffs
* r-2.14.1-3 (i686)
0/2 signoffs
* ruby-1.9.3_p125-1 (i686)
0/2 signoffs
* xf86-input-acecad-1.5.0-3 (i686)
0/2 signoffs
* xf86-input-aiptek-1.4.1-3 (i686)
0/2 signoffs
* xf86-input-evdev-2.6.99.901-1 (i686)
0/2 signoffs
* xf86-input-joystick-1.6.0-4 (i686)
0/2 signoffs
* xf86-input-keyboard-1.6.1-2 (i686)
0/2 signoffs
* xf86-input-mouse-1.7.1-3 (i686)
0/2 signoffs
* xf86-input-synaptics-1.5.99-0.1 (i686)
0/2 signoffs
* xf86-input-vmmouse-12.7.0-4 (i686)
0/2 signoffs
* xf86-input-void-1.4.0-3 (i686)
0/2 signoffs
* xf86-input-wacom-0.13.0-2 (i686)
0/2 signoffs
* xf86-video-apm-1.2.3-5 (i686)
0/2 signoffs
* xf86-video-ark-0.7.4-1 (i686)
0/2 signoffs
* xf86-video-ast-0.93.9-2 (i686)
0/2 signoffs
* xf86-video-ati-6.14.3-2 (i686)
0/2 signoffs
* xf86-video-chips-1.2.4-4 (i686)
0/2 signoffs
* xf86-video-cirrus-1.3.2-8 (i686)
0/2 signoffs
* xf86-video-dummy-0.3.5-1 (i686)
0/2 signoffs
* xf86-video-fbdev-0.4.2-6 (i686)
0/2 signoffs
* xf86-video-geode-2.11.13-1 (i686)
0/2 signoffs
* xf86-video-glint-1.2.6-2 (i686)
0/2 signoffs
* xf86-video-i128-1.3.4-5 (i686)
0/2 signoffs
* xf86-video-i740-1.3.2-8 (i686)
0/2 signoffs
* xf86-video-intel-2.17.0-3 (i686)
0/2 signoffs
* xf86-video-mach64-6.9.0-3 (i686)
0/2 signoffs
* xf86-video-mga-1.4.13-5 (i686)
0/2 signoffs
* xf86-video-neomagic-1.2.5-6 (i686)
0/2 signoffs
* xf86-video-nouveau-0.0.16_git20120210-1 (i686)
0/2 signoffs
* xf86-video-nv-2.1.18-5 (i686)
0/2 signoffs
* xf86-video-openchrome-0.2.905-1 (i686)
0/2 signoffs
* xf86-video-r128-6.8.1-8 (i686)
0/2 signoffs
* xf86-video-rendition-4.2.4-6 (i686)
0/2 signoffs
* xf86-video-s3-0.6.3-7 (i686)
0/2 signoffs
* xf86-video-s3virge-1.10.4-7 (i686)
0/2 signoffs
* xf86-video-savage-2.3.3-3 (i686)
0/2 signoffs
* xf86-video-siliconmotion-1.7.5-4 (i686)
0/2 signoffs
* xf86-video-sis-0.10.3-7 (i686)
0/2 signoffs
* xf86-video-sisusb-0.9.4-6 (i686)
0/2 signoffs
* xf86-video-tdfx-1.4.3-8 (i686)
0/2 signoffs
* xf86-video-trident-1.3.4-6 (i686)
0/2 signoffs
* xf86-video-tseng-1.2.4-6 (i686)
0/2 signoffs
* xf86-video-unichrome-0.2.7-7 (i686)
0/2 signoffs
* xf86-video-v4l-0.2.0-10 (i686)
0/2 signoffs
* xf86-video-vesa-2.3.0-8 (i686)
0/2 signoffs
* xf86-video-vmware-11.99.901-1 (i686)
0/2 signoffs
* xf86-video-voodoo-1.2.4-6 (i686)
0/2 signoffs
* xf86-video-xgixp-1.8.0-5 (i686)
0/2 signoffs
* xorg-server-1.11.99.903-1 (i686)
0/2 signoffs
* xorg-xinput-1.5.99.1-1 (i686)
0/2 signoffs
* ypbind-mt-1.33-4 (i686)
0/2 signoffs
* bluez-4.98-3 (x86_64)
0/2 signoffs
* kismet-2011_03_R2-4 (x86_64)
0/2 signoffs
* libpciaccess-0.12.902-1 (x86_64)
1/2 signoffs
* libreoffice-3.5.0-1 (x86_64)
0/2 signoffs
* libx11-1.4.99.1-1 (x86_64)
1/2 signoffs
* libxcb-1.8-2 (x86_64)
1/2 signoffs
* libxi-1.5.99.3-1 (x86_64)
0/2 signoffs
* mesa-8.0-1 (x86_64)
1/2 signoffs
* net-snmp-5.7.1-2 (x86_64)
0/2 signoffs
* networkmanager-0.9.2.0-2 (x86_64)
0/2 signoffs
* ntrack-1:16-2 (x86_64)
0/2 signoffs
* r-2.14.1-3 (x86_64)
0/2 signoffs
* ruby-1.9.3_p125-1 (x86_64)
1/2 signoffs
* xf86-input-acecad-1.5.0-3 (x86_64)
0/2 signoffs
* xf86-input-aiptek-1.4.1-3 (x86_64)
0/2 signoffs
* xf86-input-evdev-2.6.99.901-1 (x86_64)
1/2 signoffs
* xf86-input-joystick-1.6.0-4 (x86_64)
0/2 signoffs
* xf86-input-keyboard-1.6.1-2 (x86_64)
0/2 signoffs
* xf86-input-mouse-1.7.1-3 (x86_64)
0/2 signoffs
* xf86-input-synaptics-1.5.99-0.1 (x86_64)
0/2 signoffs
* xf86-input-vmmouse-12.7.0-4 (x86_64)
0/2 signoffs
* xf86-input-void-1.4.0-3 (x86_64)
0/2 signoffs
* xf86-input-wacom-0.13.0-2 (x86_64)
0/2 signoffs
* xf86-video-apm-1.2.3-5 (x86_64)
0/2 signoffs
* xf86-video-ark-0.7.4-1 (x86_64)
0/2 signoffs
* xf86-video-ast-0.93.9-2 (x86_64)
0/2 signoffs
* xf86-video-ati-6.14.3-2 (x86_64)
0/2 signoffs
* xf86-video-chips-1.2.4-4 (x86_64)
0/2 signoffs
* xf86-video-cirrus-1.3.2-8 (x86_64)
0/2 signoffs
* xf86-video-dummy-0.3.5-1 (x86_64)
0/2 signoffs
* xf86-video-fbdev-0.4.2-6 (x86_64)
0/2 signoffs
* xf86-video-glint-1.2.6-2 (x86_64)
0/2 signoffs
* xf86-video-i128-1.3.4-5 (x86_64)
0/2 signoffs
* xf86-video-i740-1.3.2-8 (x86_64)
0/2 signoffs
* xf86-video-intel-2.17.0-3 (x86_64)
1/2 signoffs
* xf86-video-mach64-6.9.0-3 (x86_64)
0/2 signoffs
* xf86-video-mga-1.4.13-5 (x86_64)
0/2 signoffs
* xf86-video-neomagic-1.2.5-6 (x86_64)
0/2 signoffs
* xf86-video-nouveau-0.0.16_git20120210-1 (x86_64)
0/2 signoffs
* xf86-video-nv-2.1.18-5 (x86_64)
0/2 signoffs
* xf86-video-openchrome-0.2.905-1 (x86_64)
0/2 signoffs
* xf86-video-r128-6.8.1-8 (x86_64)
0/2 signoffs
* xf86-video-rendition-4.2.4-6 (x86_64)
0/2 signoffs
* xf86-video-s3-0.6.3-7 (x86_64)
0/2 signoffs
* xf86-video-s3virge-1.10.4-7 (x86_64)
0/2 signoffs
* xf86-video-savage-2.3.3-3 (x86_64)
0/2 signoffs
* xf86-video-siliconmotion-1.7.5-4 (x86_64)
0/2 signoffs
* xf86-video-sis-0.10.3-7 (x86_64)
0/2 signoffs
* xf86-video-sisusb-0.9.4-6 (x86_64)
0/2 signoffs
* xf86-video-tdfx-1.4.3-8 (x86_64)
0/2 signoffs
* xf86-video-trident-1.3.4-6 (x86_64)
0/2 signoffs
* xf86-video-tseng-1.2.4-6 (x86_64)
0/2 signoffs
* xf86-video-unichrome-0.2.7-7 (x86_64)
0/2 signoffs
* xf86-video-v4l-0.2.0-10 (x86_64)
0/2 signoffs
* xf86-video-vesa-2.3.0-8 (x86_64)
0/2 signoffs
* xf86-video-vmware-11.99.901-1 (x86_64)
0/2 signoffs
* xf86-video-voodoo-1.2.4-6 (x86_64)
0/2 signoffs
* xf86-video-xgixp-1.8.0-5 (x86_64)
0/2 signoffs
* xorg-server-1.11.99.903-1 (x86_64)
1/2 signoffs
* xorg-xinput-1.5.99.1-1 (x86_64)
0/2 signoffs
* ypbind-mt-1.33-4 (x86_64)
0/2 signoffs

== Incomplete signoffs for [unknown] (3 total) ==

* ruby-docs-1.9.3_p125-1 (any)
1/2 signoffs
* libnl1-1.1-1 (i686)
0/2 signoffs
* libnl1-1.1-1 (x86_64)
0/2 signoffs


== Completed signoffs (2 total) ==

* udev-181-3 (i686)
* udev-181-3 (x86_64)


== Top five in signoffs in last 24 hours ==

1. eric - 6 signoffs
2. dan - 4 signoffs
3. tpowa - 4 signoffs
4. thomas - 4 signoffs
5. allan - 3 signoffs
 
Old 02-17-2012, 09:00 AM
"UNITED NATION AND ECOWAS"
 
Default

Good Day,

We are mandated to send total sum of $800,000 USD through Western Union by the United Nations and (ECOWAS). Processing your first payment of $10,000 USD to collect.

Sender's Name: Mary orona
MTCN: 4148545819.

You can track this money online by clicking on the Western Union Website www.westernunion.co.uk

Or you can call Western Union on 1-800-238-5772

Please get back to us immediately for the other payments.

Mr. JERRY MARTINS
E-Mail: ( werstern-unionpaymen12@msn.com)
Phone: +2348053465578
 
Old 02-17-2012, 11:31 AM
Tom Gundersen
 
Default

Hi guys,

The fix in udev-181-3 is no longer needed with the most recent kernel
packages. I have therefore removed it from [testing] and people could
revert to udev-181-2 from [core]. Keeping -3 is also safe.

Cheers,

Tom
 
Old 02-17-2012, 01:15 PM
Bob Peterson
 
Default

Hi,

This patch fixes a problem whereby gfs2_grow was failing and causing GFS2
to assert. The problem was that when GFS2's fallocate operation tried to
acquire an "allocation" it made sure the rindex was up to date, and if not,
it called gfs2_rindex_update. However, if the file being fallocated was
the rindex itself, it was already locked at that point. By calling
gfs2_rindex_update at an earlier point in time, we bring rindex up to date
and thereby avoid trying to lock it when the "allocation" is acquired.

Regards,

Bob Peterson
Red Hat File Systems

Signed-off-by: Bob Peterson <rpeterso@redhat.com>
--
fs/gfs2/file.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 310f2fb..52db4c4 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -774,6 +774,11 @@ static long gfs2_fallocate(struct file *file, int mode, loff_t offset,
if (bytes == 0)
bytes = sdp->sd_sb.sb_bsize;

+ error = gfs2_rindex_update(sdp);
+ if (error) {
+ fs_warn(sdp, "rindex update returns %d
", error);
+ return error;
+ }
gfs2_holder_init(ip->i_gl, LM_ST_EXCLUSIVE, 0, &ip->i_gh);
error = gfs2_glock_nq(&ip->i_gh);
if (unlikely(error))
 
Old 02-17-2012, 01:25 PM
Steven Whitehouse
 
Default

Hi,

If we are going to do this, then perhaps we should consider reading in
the rindex on mount? That way it will always be uptodate, and we can
refuse to mount if the rindex is damaged which is probably cleaner than
doing it after the event.

The only concern is the time taken to mount large filesystems. Having
said that the rindex should be contiguous on disk in most cases, so it
should be a fairly fast operation. Worth considering, anyway I think,

Steve.

On Fri, 2012-02-17 at 09:15 -0500, Bob Peterson wrote:
> Hi,
>
> This patch fixes a problem whereby gfs2_grow was failing and causing GFS2
> to assert. The problem was that when GFS2's fallocate operation tried to
> acquire an "allocation" it made sure the rindex was up to date, and if not,
> it called gfs2_rindex_update. However, if the file being fallocated was
> the rindex itself, it was already locked at that point. By calling
> gfs2_rindex_update at an earlier point in time, we bring rindex up to date
> and thereby avoid trying to lock it when the "allocation" is acquired.
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems
>
> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
> --
> fs/gfs2/file.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
> index 310f2fb..52db4c4 100644
> --- a/fs/gfs2/file.c
> +++ b/fs/gfs2/file.c
> @@ -774,6 +774,11 @@ static long gfs2_fallocate(struct file *file, int mode, loff_t offset,
> if (bytes == 0)
> bytes = sdp->sd_sb.sb_bsize;
>
> + error = gfs2_rindex_update(sdp);
> + if (error) {
> + fs_warn(sdp, "rindex update returns %d
", error);
> + return error;
> + }
> gfs2_holder_init(ip->i_gl, LM_ST_EXCLUSIVE, 0, &ip->i_gh);
> error = gfs2_glock_nq(&ip->i_gh);
> if (unlikely(error))
>
 
Old 02-17-2012, 01:34 PM
Bob Peterson
 
Default

----- Original Message -----
| Hi,
|
| If we are going to do this, then perhaps we should consider reading
| in
| the rindex on mount? That way it will always be uptodate, and we can
| refuse to mount if the rindex is damaged which is probably cleaner
| than
| doing it after the event.
|
| The only concern is the time taken to mount large filesystems. Having
| said that the rindex should be contiguous on disk in most cases, so
| it
| should be a fairly fast operation. Worth considering, anyway I think,
|
| Steve.

Hi,

That's not a bad idea, and we should consider it for a future enhancement.
However, I think these checks still need to be here because there are
other ways the rindex can get out of date and need to be re-read after
mount. For example, if there was another intermediate gfs2_grow done on a
different node.

BTW, I assume you saw my other patch from yesterday regarding gfs2_unlink, right?

Regards,

Bob Peterson
Red Hat File Systems


Fri Feb 17 17:30:01 2012
Return-path: <aur-general-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Fri, 17 Feb 2012 16:36:28 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:59868)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <aur-general-bounces@archlinux.org>)
id 1RyOvE-0005VR-BR
for tom@linux-archive.org; Fri, 17 Feb 2012 16:36:28 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by gerolde.archlinux.org (Postfix) with ESMTP id D757D90089;
Fri, 17 Feb 2012 09:36:25 -0500 (EST)
Received: from gerolde.archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id 6A0CE921A4
for <aur-general@archlinux.org>; Fri, 17 Feb 2012 09:36:24 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.214.44 is authorized
to use 'techlivezheng@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="techlivezheng@gmail.com";
helo=mail-bk0-f44.google.com; client-ip=209.85.214.44
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com
[209.85.214.44])
by gerolde.archlinux.org (Postfix) with ESMTPS id 0821490087
for <aur-general@archlinux.org>; Fri, 17 Feb 2012 09:36:23 -0500 (EST)
Received: by bkuw12 with SMTP id w12so3041771bku.3
for <aur-general@archlinux.org>; Fri, 17 Feb 2012 06:36:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type:content-transfer-encoding;
bh=rYKZuyLOhxwU0+F6ThIG1PkC1JEV8BHdqDC5Xnh8nnk=;
b=PNIHAUJz2wNxbHCCHq5Uk6R07HMvjHJB+akcHZ6jYU4aF/Wrl4rkvFoFXBus/jQ3Ur
yy8K30a5JUFOUv+9tD1O45kVacmHoZRirvJvg2+M/IbHahgkhNNAdhSXoWlFPaooSoQx
4nZjB5YVYuCw87WWveOL8qBFcgFMuMDx0GfKo=
Received: by 10.204.141.10 with SMTP id k10mr4418490bku.51.1329489388335; Fri,
17 Feb 2012 06:36:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.143.137 with HTTP; Fri, 17 Feb 2012 06:35:48 -0800 (PST)
In-Reply-To: <CAExbbMz4MSVtTYtq2SzSCxRtxk4OGUSihO5WYxs0+zoGrdk8 sw@mail.gmail.com>
References: <CAPYzjrSFskgQeqMuXJCQL7Gm7hah5WAZecQuBXhvx6asSKjw cw@mail.gmail.com>
<CALzgn9v95RFSgQu+x8t-iVK-SsPEjdQGeAZ_Gu2ucs2r61qSdg@mail.gmail.com>
<CAPYzjrQsUbAzWfJsxTSmUpA9CejfdGY7iHLgiBX_Feng_o4S rA@mail.gmail.com>
<CALzgn9tAoY+7SyQjemxWJzFjdfHtgpRt+18x7tF4PV8jvL1P PA@mail.gmail.com>
<CALEK4PpLLbpM9aH518qBZo0HS1j=Z05uZDbTmUT_w7e9P_yY uQ@mail.gmail.com>
<CAJKF5uh+kbmeguufPf=TiA=_e-x41atFJbj_YavFceBMe9oD_Q@mail.gmail.com>
<CA+rnASvgXQq_o+=aFZ8eArxQh0JWgyOrWNHPGX=3d5-quoSWbw@mail.gmail.com>
<CAExbbMz4MSVtTYtq2SzSCxRtxk4OGUSihO5WYxs0+zoGrdk8 sw@mail.gmail.com>
From: =?UTF-8?B?6YOR5paH6L6JKFRlY2hsaXZlIFpoZW5nKQ==?=
<techlivezheng@gmail.com>
Date: Fri, 17 Feb 2012 22:35:48 +0800
Message-ID: <CAPYzjrQEYpYF7wwt=R=c-6P=2FbAWX=YWS4cYkfd7i-HMfZ7gA@mail.gmail.com>
To: "Discussion about the Arch User Repository (AUR)"
<aur-general@archlinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [aur-general] Which aur uploader is better, aurploader or burp?
X-BeenThere: aur-general@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: "Discussion about the Arch User Repository (AUR)"
<aur-general@archlinux.org>
List-Id: "Discussion about the Arch User Repository (AUR)"
<aur-general.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/aur-general>,
<mailto:aur-general-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/aur-general>
List-Post: <mailto:aur-general@archlinux.org>
List-Help: <mailto:aur-general-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/aur-general>,
<mailto:aur-general-request@archlinux.org?subject=subscribe>
Errors-To: aur-general-bounces@archlinux.org
Sender: aur-general-bounces@archlinux.org

2012/2/17 SanskritFritz <sanskritfritz@gmail.com>:
> 2012/2/17 C=E9dric Girard <girard.cedric@gmail.com>:
>> 2012/2/17 Alireza Savand <alireza.savand@gmail.com>
>>
>>> For downloading yes of course it's nice to have one like yaourt, but fo=
r
>>> uploading it's little bit useless.
>>>
>>
>> No, it's really useful when you are updating your PKGBUILD on an headles=
s
>> server.
>
> It *is* very useful. I maintain numerous aur packages, and using burp
> is very convenient. I just do a
>
> #!/usr/bin/fish
> makepkg --source
> burp (ls --sort=3Dtime *src.tar.gz | head -1)
>
> Previously I used aurploader (anything associated with Xyne is
> appealing since the times of bauerbill), but it forgot the
bauerbill is fantastic,espacially its CPAN support,save lots of time.
> user/password too quickly, so I tried burp, which fits my needs better
You mean that aurploader can not keep username and passname in config file?
> in this regard. Both are great programs.
 
Old 02-17-2012, 01:42 PM
Steven Whitehouse
 
Default

Hi,

On Fri, 2012-02-17 at 09:34 -0500, Bob Peterson wrote:
> ----- Original Message -----
> | Hi,
> |
> | If we are going to do this, then perhaps we should consider reading
> | in
> | the rindex on mount? That way it will always be uptodate, and we can
> | refuse to mount if the rindex is damaged which is probably cleaner
> | than
> | doing it after the event.
> |
> | The only concern is the time taken to mount large filesystems. Having
> | said that the rindex should be contiguous on disk in most cases, so
> | it
> | should be a fairly fast operation. Worth considering, anyway I think,
> |
> | Steve.
>
> Hi,
>
> That's not a bad idea, and we should consider it for a future enhancement.
> However, I think these checks still need to be here because there are
> other ways the rindex can get out of date and need to be re-read after
> mount. For example, if there was another intermediate gfs2_grow done on a
> different node.
>
There is no locking here to prevent the rindex from becoming out of date
again, immediately after this call, so that might still be picked up by
he lower level code and result in another problem if I'm reading the
original bug report correctly.

An alternative way to resolve this is just to check whether the rindex
is already locked before trying to lock it again at the lower level. Or,
I guess, we could even do both.

> BTW, I assume you saw my other patch from yesterday regarding gfs2_unlink, right?
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems

Yes, I was just about to take a look at it - I've been a little waylaid
with other things in the last couple of days,

Steve.
 

Thread Tools




All times are GMT. The time now is 11:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org