spam on this list

spam on this list

[Jean Delvare]

> Sorry, I know the spam is a hassle.  It would be nice to have a 
> moderator who can screen everything, but that takes too much time and 
> delays emails.  Right now there is a procmail script which tags likely
> 
> spam and puts in a X-SBClass: header.  If it is followed by 'Spam',
> then it is almost certainly spam, if it is followed by 'Blocked', then
> it scores high as being potential spam.  You should be able to set
> some rules in your mail client to throw those emails into a seperate
> folder.  It's not bullet proof (some legit mails get tagged wrong, and
> vice versa), but it seems to be about 95% accurate in my experience.
> 
> BTW- If there are some recommendations on better alternatives, let me
> know.

Actually, I tend to find that it works rather well. I have filtered on
X-SBClass = Blocked and, even if it rejects some legitimate posts, it
is generally efficient. I think that X-SBClass = Spam are already
rejected at higher level ? I don't remember seeing anything like this in
the mails I receive.

And, Markus, believe me, there is a lot less spam now that there used to
be ;) (but of course I'd like to see spam eradicated from Earth... what
times are we living now, seriously; looks to me like the middle-age of
Internet).

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

spam on this list

[Philip Edelbrock]

Sorry, I know the spam is a hassle.  It would be nice to have a 
moderator who can screen everything, but that takes too much time and 
delays emails.  Right now there is a procmail script which tags likely 
spam and puts in a X-SBClass: header.  If it is followed by 'Spam', then 
it is almost certainly spam, if it is followed by 'Blocked', then it 
scores high as being potential spam.  You should be able to set some 
rules in your mail client to throw those emails into a seperate folder.  
It's not bullet proof (some legit mails get tagged wrong, and vice 
versa), but it seems to be about 95% accurate in my experience.

BTW- If there are some recommendations on better alternatives, let me know.


Phil

Markus Schorer wrote:

>hi,
>
>being rather new here it seems to me that more spam is going 
>over this list than i2c related stuff.
>
>any chance of getting the spam excluded?
>
>regards,
>
>  
>

spam on this list

[Pierre Frenkiel]

I'm surprised to recieve  spams rather often from this list. I'm
subscribed to a big number of lists, and it's the only for which
this occurs. Would it be possible to refuse posts from non-members ?

best regards,
-- 
Pierre Frenkiel

partition 100% full No space left on device. looks like xfs is corrupted or a bug

[Lista Unx]

[-- Attachment #1.1: Type: text/plain, Size: 7643 bytes --]

Hello xfs experts,

I am crawling in the dark from few days and I have no idea how to fix the following problem. On a centos 7 system:

# uname -a
Linux 1a 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

df is reporting 100% full of / and du is reporting only 1.7G usage from 50GB available (less than 4%). I want to mention that / is xfs. See below:

# df -a|grep ^/
/dev/mapper/centos-root  52403200 52400396      2804 100% /
                                     ^^^^^^^^^^   ^^^^^^^^^^
/dev/sda1                  503040   131876    371164  27% /boot
/dev/mapper/centos-home 210529792    35204 210494588   1% /home

du is estimating just 1.7G usage of /
# du -sch /* --exclude=home --exclude=boot
0       /bin
0       /dev
25M     /etc
0       /lib
0       /lib64
744K    /luarocks-2.3.0
0       /media
0       /mnt
125M    /openresty-1.9.7.4
0       /opt
420K    /root
49M     /run
0       /sbin
0       /srv
0       /sys
0       /tmp
1.3G    /usr
227M    /var
1.7G    total
[root@localhost ~]#

df is also reporting 80% of inode usage:

# df -i
Filesystem                 Inodes IUsed     IFree IUse% Mounted on
/dev/mapper/centos-root     78160 66218     11942   85% /
                                       ^^^^^^^^
devtmpfs                  8218272   519   8217753    1% /dev
tmpfs                     8221010     1   8221009    1% /dev/shm
tmpfs                     8221010   648   8220362    1% /run
tmpfs                     8221010    13   8220997    1% /sys/fs/cgroup
/dev/sda1                  509952   330    509622    1% /boot
/dev/mapper/centos-home 210632704    99 210632605    1% /home
tmpfs                     8221010     1   8221009    1% /run/user/0
#

/ partition is created on top of a LVM having also 50GB size.

# lvdisplay /dev/centos/root
  --- Logical volume ---
  LV Path                /dev/centos/root
  LV Name                root
  VG Name                centos

  LV Status              available
  # open                 1
  LV Size                50.00 GiB
  Current LE             12800
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

I've already checked against rootkit without finding anything wrong!

I have another system, identical with this one which is healthy. The only difference I found between those systems is regarding max number of inodes available on / (which has the same size, 50GB on booth servers). On the second one (healthy), max number of inodes are ~52 milions and not only just ~85.000 as are reported on "seek" server.

# df -i|grep ^/
/dev/mapper/centos-root  52424704 66137  52358567    1% /
                                   ^^^^^^^^^^^^^
/dev/sda1                                  509952   330    509622    1% /boot
/dev/mapper/centos-home 210632704    26 210632678    1% /home
[root@localhost ~]#

Suspected also large number of files on /. Counted total number of files and or booth servers are the same: ~180K. So no difference here.

Look to find also files larger than 100M and on booth servers and found just 1 (104M size):

find / -type f -size +100000k -exec ls -lh {} \;
#
/usr/lib/locale/locale-archive
#

Looking to find files larger than 10M, I found just ~20 on booth servers.

# find / -type f -size +10000k -exec ls -lh {} \; |wc -l
16
#

So for sure, there are NO files exhausting free space.

On booth servers, number of used inodes are identical: ~66K. Also xfs_info report is identical for booth. What is different is number of AVAILABLE inodes: 85K (on seek node) vs 52 milion (on healthy node)!!! How is possible that!!! Booth servers has the same size (50GB) for /!

#lsof -nP |grep -i delete|wc -l
0
#find /proc/*/fd -ls | grep -i dele|wc -l
0

so lsof and find does not report anything wrong (any file deleted and still open)!

reboot does not fix the problem, / remain 100% full

After reboot, on 25th July:

# df -ah|grep centos-root
/dev/mapper/centos-root   50G   50G  4.0M 100% /
#

Also max number of inodes = 67k:
# df -i
Filesystem                 Inodes IUsed     IFree IUse% Mounted on
/dev/mapper/centos-root     66960 66165       795   99% /
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
devtmpfs                  8218272   519   8217753    1% /dev
tmpfs                     8221010     1   8221009    1% /dev/shm
tmpfs                     8221010   630   8220380    1% /run
tmpfs                     8221010    13   8220997    1% /sys/fs/cgroup
/dev/sda1                  509952   330    509622    1% /boot
/dev/mapper/centos-home 210632704    28 210632676    1% /home
tmpfs                     8221010     1   8221009    1% /run/user/0
#

Lets try to run intentionally xfs_grow (which normally should not produce any change)

# xfs_growfs /dev/mapper/centos-root
meta-data=/dev/mapper/centos-root isize=256    agcount=16, agsize=819136 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=13106176, imaxpct=25
         =                       sunit=64     swidth=64 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=6400, version=2
         =                       sectsz=512   sunit=64 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 13106176 to 13107200
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#

Partition remain the same, 50GB size:
[root@nl-hvs-ov001a ~]# df -ah|grep centos-root
/dev/mapper/centos-root   50G   50G  4.0M 100% /

But number of inodes INCREASED with more tha 20%!!!
# df -i
Filesystem                 Inodes IUsed     IFree IUse% Mounted on
/dev/mapper/centos-root     83200 66165     17035   80% /
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
devtmpfs                  8218272   519   8217753    1% /dev
tmpfs                     8221010     1   8221009    1% /dev/shm
tmpfs                     8221010   630   8220380    1% /run
tmpfs                     8221010    13   8220997    1% /sys/fs/cgroup
/dev/sda1                  509952   330    509622    1% /boot
/dev/mapper/centos-home 210632704    28 210632676    1% /home
tmpfs                     8221010     1   8221009    1% /run/user/0
#

On 27July without changing anything there, max number inodes available for / decreased to ~67k (the same size like 2 days ago, before xfs_grow)!

# df -i
Filesystem                 Inodes IUsed     IFree IUse% Mounted on
/dev/mapper/centos-root     67024 66225       799   99% /
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
devtmpfs                  8218272   519   8217753    1% /dev
tmpfs                     8221010     1   8221009    1% /dev/shm
tmpfs                     8221010   632   8220378    1% /run
tmpfs                     8221010    13   8220997    1% /sys/fs/cgroup
/dev/mapper/centos-home 210632704    99 210632605    1% /home
/dev/sda1                  509952   330    509622    1% /boot
tmpfs                     8221010     1   8221009    1% /run/user/0
#

Please note that all that time, number of files remain unchanged ~180K, the same for inodes used, the number remain constant ~66K. Just max number of inodes available decreased which is an abnormal behavior.

How can be fixed? Looks like xfs is crrupted or like a bug.

Thanks in advance for help.
Alex

[-- Attachment #1.2: Type: text/html, Size: 18138 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: partition 100% full No space left on device. looks like xfs iscorrupted or a bug

[Lista Unx]

----- Original Message ----- 
From: "Dave Chinner" <david@fromorbit.com>
To: "Lista Unx" <lista.unx@gmail.com>
Cc: <xfs@oss.sgi.com>
Sent: Saturday, July 30, 2016 2:35 AM
Subject: Re: partition 100% full No space left on device. looks like xfs 
iscorrupted or a bug


> Ok, so you followed my advice on why you couldn't post to the list,

Yes, I've created a new gmail account especially to be able to post to this 
mailing list which is filtering very seriously legit messages comming from 
legit usres, just because they are comming from yahoo accounts (servers) ... 
but is allowing ANYONE else to post here WITHOUT having valid subscription 
and also WITHOUT any minimal intention to post here something which has or 
is related to XFS. Just in last days, I was informed about new microwave 
acquisition, plastic delivery, or any other craps arriving here from a 
"trusted and very legit" source, like gmail. That's sound like really a very 
good job!

> but you ignored my answer as to the cause of the changing numbers of
> inodes. I'll repeat it here for the benefit of everyone, so they
> don't waste time chasing ghosts.

No, not at all, is not my style. Just mentioned twice to you, that we are 
not talking about number of inode usage. we are talking about max number of 
inodes which differ with at least 10 times less, for partitions with THE 
SAME SIZE AND USAGE!

> That is, inodes are dynamically allocated so the number of supported
> inodes is directly proportional to the amount of free space left in
> the filesystem. You have filesystems with different amounts

NO! Booth systems are almost identical (minor differencies) and this has 
been stated very clear on my first post. That's not necessary to comment 
each line in my post, just to point us in the right direction.

> That's probably because there are open but unlinked files present in
> the filesystem, and du will not find them. e.g. large O_TMPFILE
> files, or files that applications are using as scratch space. You
> may even have zombie processes hanging about holding unlinked files
> open.

Has been mentioned on my first post, reboot does not solve problem, there 
are no (large, small or any kind of files) exahusting inodes!

>
> lsof might find those files, it might not. There might also be
> orphan inodes on the unlinked lists, and without an unclean shutdown
> log recovery won't process them.

Yes, also mentioned on my first post, lsof does not show anomalies ...

> So it may simply be best to run
> sync, then press the reset button to do a hard restart which
> will trigger log recovery on restart.

The same, mentioned on my first post, reboot (which will clean zombies) does 
not resolve issue.

> If the problem still persists,
> then xfs_repair is really the only option to find out where the
> space has gone and recover it.

Yes, that was also my conclusion BEFORE to post here. I did not have (yet) 
possibility to put / partition offline (or to not be mounted in order to run 
xfs_repair) and that's I asked here, considering that someone in the past 
encountered a simillar problem or in case not, there are few other things to 
be done, in order to consider that the last step to follow is to put server 
down for deep investigation.

I am still waiting approval to put server down for deep investigations 
(xfs_repaid & friends).

Have a nice day,
Alex 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Spam on this list [Was: Re: partition 100% full No space left on device. looks like xfs iscorrupted or a bug]

[Carlos E. R.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Monday, 2016-08-01 at 15:00 +0300, Lista Unx wrote:

> Yes, I've created a new gmail account especially to be able to post to this 
> mailing list which is filtering very seriously legit messages comming from 
> legit usres, just because they are comming from yahoo accounts (servers) ... 
> but is allowing ANYONE else to post here WITHOUT having valid subscription and 
> also WITHOUT any minimal intention to post here something which has or is 
> related to XFS. Just in last days, I was informed about new microwave 
> acquisition, plastic delivery, or any other craps arriving here from a 
> "trusted and very legit" source, like gmail. That's sound like really a very 
> good job!

:-)

Yes, Spam is bad in this list, and has increased recently. You will 
find, however, that gmail does a good job of filtering them out: you 
only have to mark as spam those that it does not detect, and conversely, 
clear out the false positives. It learns soon.

I also have problems with my ISP and Spam on this list.


You will find that the people on this list are very knowledgeable and 
will try to help you on your problem with XFS. Spam is not a thing on 
their power, though X'-)

- -- 
Cheers,
        Carlos E. R.
        (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAleh6p8ACgkQtTMYHG2NR9VwbACfQ48V7GoSWDjxkscKMZZBGbeW
qf8An0XDo7JRY1wOjQlVAqyE3Of/t6DG
=n207
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list [Was: Re: partition 100% full No space left on device. looks like xfs iscorrupted or a bug]

[Martin Steigerwald]

Am Mittwoch, 3. August 2016, 14:59:11 CEST schrieb Carlos E. R.:
> On Monday, 2016-08-01 at 15:00 +0300, Lista Unx wrote:
> > Yes, I've created a new gmail account especially to be able to post to
> > this
> > mailing list which is filtering very seriously legit messages comming from
> > legit usres, just because they are comming from yahoo accounts (servers)
> > ... but is allowing ANYONE else to post here WITHOUT having valid
> > subscription and also WITHOUT any minimal intention to post here
> > something which has or is related to XFS. Just in last days, I was
> > informed about new microwave acquisition, plastic delivery, or any other
> > craps arriving here from a "trusted and very legit" source, like gmail.
> > That's sound like really a very good job!
> :
> :-)
> 
> Yes, Spam is bad in this list, and has increased recently. You will
> find, however, that gmail does a good job of filtering them out: you
> only have to mark as spam those that it does not detect, and conversely,
> clear out the false positives. It learns soon.
> 
> I also have problems with my ISP and Spam on this list.
> 
> 
> You will find that the people on this list are very knowledgeable and
> will try to help you on your problem with XFS. Spam is not a thing on
> their power, though X'-)

Lista, Carlos, I recommend: If you are concerned about spam on the list 
contact the listmasters of it. They are the ones that can address it globally 
for the list.

Or… improve your spamfilters. I did not see any of the spam mails you 
mentioned, Lista, as my mailserver rejected them on the SMTP level.

Discussing spam topics here just adds to the noise.

-- 
Martin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list [Was: Re: partition 100% full No space left on device. looks like xfs iscorrupted or a bug]

[Carlos E. R.]

[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]

On 2016-08-03 15:21, Martin Steigerwald wrote:

> Lista, Carlos, I recommend: If you are concerned about spam on the list 
> contact the listmasters of it. They are the ones that can address it globally 
> for the list.

Oh, I did, long ago. Still waiting.

> Or… improve your spamfilters. I did not see any of the spam mails you 
> mentioned, Lista, as my mailserver rejected them on the SMTP level.

So does mine. Now and then it rejects spam, and the list automatically
stops my subscription as a consequence.

-- 
Cheers / Saludos,

		Carlos E. R.
		(from 13.1 x86_64 "Bottle" at Telcontar)


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list

[Dave Chinner]

On Wed, Aug 03, 2016 at 03:34:58PM +0200, Carlos E. R. wrote:
> On 2016-08-03 15:21, Martin Steigerwald wrote:
> 
> > Lista, Carlos, I recommend: If you are concerned about spam on the list 
> > contact the listmasters of it. They are the ones that can address it globally 
> > for the list.
> 
> Oh, I did, long ago. Still waiting.

Yes, that is the fundamental issue - spam filtering is essentially
controlled by SGI's internal infrastructure, which we have little
option on.

What it comes down to is whether we continue to use this list
(xfs@oss.sgi.com) or whether we move to linux-xfs@vger.kernel.org
so we get much more robust and up-to-date spam filtering. The issue
with doing this is forcing everyone to resubscribe, and then
capturing everything that is still sent to xfs@oss.sgi.com.

That said, I'm seriously tempted right now just to say "we're moving
to vger" and asking everyone to resubscribe to that list, and then
making xfs@oss.sgi.com respond with "list moved to vger, please
repost there". i.e. not even put a forwarding gateway in place.

If we do that, then I'll also shut down all the XFS git trees on
oss.sgi.com - I'll add commits to the them to say "go to
kernel.org". I'll need to work something out for the tarball
releases, but kernel.org does have functionality for that, too, so
that may just be a small change of process on my end (i.e. use kup).
Once that is done, we'll be running completely on community provided
infrastructure....

Thoughts?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list

[Darrick J. Wong]

On Thu, Aug 04, 2016 at 09:15:29AM +1000, Dave Chinner wrote:
> On Wed, Aug 03, 2016 at 03:34:58PM +0200, Carlos E. R. wrote:
> > On 2016-08-03 15:21, Martin Steigerwald wrote:
> > 
> > > Lista, Carlos, I recommend: If you are concerned about spam on the list 
> > > contact the listmasters of it. They are the ones that can address it globally 
> > > for the list.
> > 
> > Oh, I did, long ago. Still waiting.
> 
> Yes, that is the fundamental issue - spam filtering is essentially
> controlled by SGI's internal infrastructure, which we have little
> option on.
> 
> What it comes down to is whether we continue to use this list
> (xfs@oss.sgi.com) or whether we move to linux-xfs@vger.kernel.org
> so we get much more robust and up-to-date spam filtering. The issue
> with doing this is forcing everyone to resubscribe, and then
> capturing everything that is still sent to xfs@oss.sgi.com.
> 
> That said, I'm seriously tempted right now just to say "we're moving
> to vger" and asking everyone to resubscribe to that list, and then
> making xfs@oss.sgi.com respond with "list moved to vger, please
> repost there". i.e. not even put a forwarding gateway in place.
> 
> If we do that, then I'll also shut down all the XFS git trees on
> oss.sgi.com - I'll add commits to the them to say "go to
> kernel.org". I'll need to work something out for the tarball
> releases, but kernel.org does have functionality for that, too, so
> that may just be a small change of process on my end (i.e. use kup).
> Once that is done, we'll be running completely on community provided
> infrastructure....
> 
> Thoughts?

YAY!

By the way, could we update the docs on
http://xfs.org/index.php/XFS_Papers_and_Documentation ?

The filesystem structure guide is a little out of date.

(The user guide probably is too, but as I've only been sending patches
for the disk format guide I'm keeping my mouth shut about the others.)

--D

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list

[Carlos E. R.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2016-08-04 01:15, Dave Chinner wrote:
> On Wed, Aug 03, 2016 at 03:34:58PM +0200, Carlos E. R. wrote:
>> On 2016-08-03 15:21, Martin Steigerwald wrote:

...

> Thoughts?

I have no objection to either staying or moving :-)

That is, I can live with the spam, and I can live with the move. You
do not need to care for people like me, we are just "users" ;-)

It is mostly the contributors you have to mind most.

I suppose that as log as you leave an autoresponder it will be Ok.

So go ahead when you wish :-)

- -- 
Cheers / Saludos,

		Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAleikaMACgkQja8UbcUWM1x4AgD/b5NpxNS0O1LFuYAlBpdvMG7R
Ikr5YoxtNqLT9EcT8YQA/1O9P1p977AEOSlHxbxP3YMB4uEsea8p2PCaGINCUrKr
=OIsJ
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list

[Lista Unx]

----- Original Message ----- 
From: "Dave Chinner" <david@fromorbit.com>
To: "Carlos E. R." <robin.listas@telefonica.net>
Cc: "XFS mail list" <xfs@oss.sgi.com>
Sent: Thursday, August 04, 2016 2:15 AM
Subject: Re: Spam on this list


> Yes, that is the fundamental issue - spam filtering is essentially
> controlled by SGI's internal infrastructure, which we have little
> option on.
>
> What it comes down to is whether we continue to use this list
> (xfs@oss.sgi.com) or whether we move to linux-xfs@vger.kernel.org
> so we get much more robust and up-to-date spam filtering. The issue
> with doing this is forcing everyone to resubscribe, and then
> capturing everything that is still sent to xfs@oss.sgi.com.
>
> That said, I'm seriously tempted right now just to say "we're moving
> to vger" and asking everyone to resubscribe to that list, and then
> making xfs@oss.sgi.com respond with "list moved to vger, please
> repost there". i.e. not even put a forwarding gateway in place.
>
> If we do that, then I'll also shut down all the XFS git trees on
> oss.sgi.com - I'll add commits to the them to say "go to
> kernel.org". I'll need to work something out for the tarball
> releases, but kernel.org does have functionality for that, too, so
> that may just be a small change of process on my end (i.e. use kup).
> Once that is done, we'll be running completely on community provided
> infrastructure....
>
> Thoughts?

I completely agree, is a good idea to move to a new place where more filters 
are already in place. It is a small change on user's side and benefits are 
for everyone. I cannot see any cons to not do it. It probably will be the 
best to keep also a message for newcommers and also for robots, that list 
has been moved to vger and new way to subscribe. 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: Spam on this list

[Troy McCorkell]

On Wed, Aug 03,2016 at 6:15PM Dave Chinner wrote:
>On Wed, Aug 03, 2016 at 03:34:58PM +0200, Carlos E. R. wrote:
>> On 2016-08-03 15:21, Martin Steigerwald wrote:
>>
>> > Lista, Carlos, I recommend: If you are concerned about spam on the list
>> > contact the listmasters of it. They are the ones that can address it globally
>> > for the list.
>>
>> Oh, I did, long ago. Still waiting.
>
>Yes, that is the fundamental issue - spam filtering is essentially
>controlled by SGI's internal infrastructure, which we have little
>option on.
>
>What it comes down to is whether we continue to use this list
>(xfs@oss.sgi.com) or whether we move to linux-xfs@vger.kernel.org
>so we get much more robust and up-to-date spam filtering. The issue
>with doing this is forcing everyone to resubscribe, and then
>capturing everything that is still sent to xfs@oss.sgi.com.
>
>That said, I'm seriously tempted right now just to say "we're moving
>to vger" and asking everyone to resubscribe to that list, and then
>making xfs@oss.sgi.com respond with "list moved to vger, please
>repost there". i.e. not even put a forwarding gateway in place.
>
>If we do that, then I'll also shut down all the XFS git trees on
>oss.sgi.com - I'll add commits to the them to say "go to
>kernel.org". I'll need to work something out for the tarball
>releases, but kernel.org does have functionality for that, too, so
>that may just be a small change of process on my end (i.e. use kup).
>Once that is done, we'll be running completely on community provided
>infrastructure....
>
>Thoughts?
>
>Cheers,
>
>Dave.
>--
>Dave Chinner
>david@fromorbit.com

Dave,

It's probably the best option to move the mailing list to vger.
Let me know what we can do to facilitate the move.

Thanks,
Troy

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list

[Martin Steigerwald]

Am Donnerstag, 4. August 2016, 09:15:29 CEST schrieb Dave Chinner:
> On Wed, Aug 03, 2016 at 03:34:58PM +0200, Carlos E. R. wrote:
> > On 2016-08-03 15:21, Martin Steigerwald wrote:
> > > Lista, Carlos, I recommend: If you are concerned about spam on the list
> > > contact the listmasters of it. They are the ones that can address it
> > > globally for the list.
> > 
> > Oh, I did, long ago. Still waiting.
> 
> Yes, that is the fundamental issue - spam filtering is essentially
> controlled by SGI's internal infrastructure, which we have little
> option on.
> 
> What it comes down to is whether we continue to use this list
> (xfs@oss.sgi.com) or whether we move to linux-xfs@vger.kernel.org
> so we get much more robust and up-to-date spam filtering. The issue
> with doing this is forcing everyone to resubscribe, and then
> capturing everything that is still sent to xfs@oss.sgi.com.
> 
> That said, I'm seriously tempted right now just to say "we're moving
> to vger" and asking everyone to resubscribe to that list, and then
> making xfs@oss.sgi.com respond with "list moved to vger, please
> repost there". i.e. not even put a forwarding gateway in place.
> 
> If we do that, then I'll also shut down all the XFS git trees on
> oss.sgi.com - I'll add commits to the them to say "go to
> kernel.org". I'll need to work something out for the tarball
> releases, but kernel.org does have functionality for that, too, so
> that may just be a small change of process on my end (i.e. use kup).
> Once that is done, we'll be running completely on community provided
> infrastructure....
> 
> Thoughts?

Nice, so this time discussing spam on the list on the list may have a nice 
effect in the end.

I completely agree and have no issues with resubscribung there.

Thank you,
-- 
Martin

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Spam on this list

[Carlos Eduardo Maiolino]

>> 
>> That said, I'm seriously tempted right now just to say "we're moving 
>> to vger" and asking everyone to resubscribe to that list, and then 
>> making xfs@oss.sgi.com respond with "list moved to vger, please 
>> repost there". i.e. not even put a forwarding gateway in place. 
>> 
>> If we do that, then I'll also shut down all the XFS git trees on 
>> oss.sgi.com - I'll add commits to the them to say "go to 
>> kernel.org". I'll need to work something out for the tarball 
>> releases, but kernel.org does have functionality for that, too, so 
>> that may just be a small change of process on my end (i.e. use kup). 
>> Once that is done, we'll be running completely on community provided 
>> infrastructure.... 
>> 
>> Thoughts? 

>Nice, so this time discussing spam on the list on the list may have a nice 
>effect in the end.
>
>I completely agree and have no issues with resubscribung there. 
>
>Thank you, 
>-- 
>Martin 

+1 here.

Honestly, I don't believe that moving to vger will be a big trouble for anyone other than the list maintainer who will need to set auto-respond messages.
And we have the advantage of moving it to a community provided infra as you said.

Let me know if you need any help with it, I'll be glad to help in this change



-- 
--Carlos

P.S. Martin, I apologize for the dup'ed e-mail, my MUA tricked me and I didn't copy xfs list on my previous reply..

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs