On Wed, Apr 14, 2021 at 04:53:06PM +0200, Vitaly Zaitsev via devel wrote:
> On 14.04.2021 16:27, Tomas Tomecek wrote:
> > Could you, please, be more constructive and say what the actual
> > problems are for you with such repositories?
>
> 1. Some upstream repositories (Qt, Chromium, Linux kernel)
On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should
> be the preferred way. Would there be anybody really missing this
> functionality?
For what i
On Tue, Nov 24, 2020 at 08:06:41PM +0100, Joël Krähemann wrote:
> On Tue, Nov 24, 2020 at 3:27 PM Neal Gompa wrote:
> > That being said, I have spoken to a few audio engineers, and basically
> > none of them use ALSA directly. They can't because ALSA doesn't
> > support mixing properly, among ot
On Mon, Jun 29, 2020 at 01:33:37PM -0400, Josef Bacik wrote:
> On 6/29/20 12:23 PM, J. Bruce Fields wrote:
> > Maybe not a desktop question, but do you know btrfs's change
> > attribute/i_version status? Does it default to bumping i_version on
> > each change, or does t
Maybe not a desktop question, but do you know btrfs's change
attribute/i_version status? Does it default to bumping i_version on
each change, or does that still need to be opted in? And has anyone
measured the performance delta (i_version vs. noi_version) recently?
--b.
_
On Tue, Feb 13, 2018 at 07:01:22AM +, Terry Barnaby wrote:
> The transaction system allows the write delegation to send the data to the
> servers RAM without the overhead of synchronous writes to the disk.
As far as I'm concerned this problem is already solved--did you miss the
discussion of W
On Mon, Feb 05, 2018 at 06:06:29PM -0500, J. Bruce Fields wrote:
> Or this?:
>
>
> https://www.newegg.com/Product/Product.aspx?Item=N82E16820156153&cm_re=ssd_power_loss_protection-_-20-156-153-_-Product
Ugh, Anandtech explains that their marketing is misleading, that driv
On Mon, Feb 12, 2018 at 08:12:58PM +, Terry Barnaby wrote:
> On 12/02/18 17:35, Terry Barnaby wrote:
> > On 12/02/18 17:15, J. Bruce Fields wrote:
> > > On Mon, Feb 12, 2018 at 05:09:32PM +, Terry Barnaby wrote:
> > > > One thing on this, that I forgo
On Mon, Feb 12, 2018 at 05:35:49PM +, Terry Barnaby wrote:
> Well that seems like a major drop off, I always thought that fsync() would
> work in this case.
No, it never has.
> I don't understand why fsync() should not operate as
> intended ? Sounds like this NFS async thing needs some work !
On Mon, Feb 12, 2018 at 05:09:32PM +, Terry Barnaby wrote:
> One thing on this, that I forgot to ask, doesn't fsync() work properly with
> an NFS server side async mount then ?
No.
If a server sets "async" on an export, there is absolutely no way for a
client to guarantee that data reaches di
On Mon, Feb 12, 2018 at 09:08:47AM +, Terry Barnaby wrote:
> On 09/02/18 08:25, nicolas.mail...@laposte.net wrote:
> > - Mail original -
> > De: "Terry Barnaby"
> > > If
> > > it was important to get the data to disk it would have been using
> > > fsync(), FS sync, or some other transac
On Thu, Feb 08, 2018 at 08:21:44PM +, Terry Barnaby wrote:
> Doesn't fsync() and perhaps sync() work across NFS then when the server has
> an async export,
No.
On a local filesystem, a file create followed by a sync will ensure
the file create reaches disk. Normally on NFS, the same is true-
On Tue, Feb 06, 2018 at 08:18:27PM +, Terry Barnaby wrote:
> Well, when a program running on a system calls open(), write() etc. to the
> local disk FS the disk's contents is not actually updated. The data is in
> server buffers until the next sync/fsync or some time has passed. So, in
> your p
On Tue, Feb 06, 2018 at 06:49:28PM +, Terry Barnaby wrote:
> On 05/02/18 14:52, J. Bruce Fields wrote:
> > > Yet another poor NFSv3 performance issue. If I do a "ls -lR" of a certain
> > > NFS mounted directory over a slow link (NFS over Openvpn over FTTP
> &
On Thu, Feb 01, 2018 at 08:29:49AM +, Terry Barnaby wrote:
> 1. Have an OPEN-SETATTR-WRITE RPC call all in one and a SETATTR-CLOSE call
> all in one. This would reduce the latency of a small file to 1ms rather than
> 3ms thus 66% faster. Would require the client to delay the OPEN/SETATTR
> unti
On Mon, Feb 05, 2018 at 08:21:06AM +, Terry Barnaby wrote:
> On 01/02/18 08:29, Terry Barnaby wrote:
> > On 01/02/18 01:34, Jeremy Linton wrote:
> > > On 01/31/2018 09:49 AM, J. Bruce Fields wrote:
> > > > On Tue, Jan 30, 2018 at 01:52:49PM -0600, Jeremy Linton w
On Wed, Jan 31, 2018 at 07:34:24PM -0600, Jeremy Linton wrote:
> On 01/31/2018 09:49 AM, J. Bruce Fields wrote:
> > In the kernel compile case there's probably also a lot of re-opening and
> > re-reading files too? NFSv4 is chattier there too. Read delegations
> > shou
On Tue, Jan 30, 2018 at 01:52:49PM -0600, Jeremy Linton wrote:
> Have you tried this with a '-o nfsvers=3' during mount? Did that help?
>
> I noticed a large decrease in my kernel build times across NFS/lan a while
> back after a machine/kernel/10g upgrade. After playing with mount/export
> option
On Tue, Jan 30, 2018 at 10:30:04PM +, Terry Barnaby wrote:
> Also, on the 0.5ms. Is this effectively the 1ms system tick ie. the NFS
> processing is not processing based on the packet events (not pre-emptive)
> but on the next system tick ?
>
> An ICMP ping is about 0.13ms (to and fro) between
On Tue, Jan 30, 2018 at 04:31:58PM -0500, J. Bruce Fields wrote:
> On Tue, Jan 30, 2018 at 07:03:17PM +, Terry Barnaby wrote:
> > It looks like each RPC call takes about 0.5ms. Why do there need to be some
> > many RPC calls for this ? The OPEN call could set the attribs, no n
On Tue, Jan 30, 2018 at 07:03:17PM +, Terry Barnaby wrote:
> It looks like each RPC call takes about 0.5ms. Why do there need to be some
> many RPC calls for this ? The OPEN call could set the attribs, no need for
> the later GETATTR or SETATTR calls.
The first SETATTR (which sets ctime and mt
On Tue, Jan 30, 2018 at 12:31:22PM -0500, J. Bruce Fields wrote:
> On Tue, Jan 30, 2018 at 04:49:41PM +, Terry Barnaby wrote:
> > I have just tried running the untar on our work systems. These are again
> > Fedora27 but newer hardware.
> > I set one of the servers N
On Tue, Jan 30, 2018 at 04:49:41PM +, Terry Barnaby wrote:
> I have just tried running the untar on our work systems. These are again
> Fedora27 but newer hardware.
> I set one of the servers NFS exports to just rw (removed the async option in
> /etc/exports and ran exportfs -arv).
> Remounted
On Tue, Jan 30, 2018 at 03:29:41PM +, Terry Barnaby wrote:
> On 30/01/18 15:09, J. Bruce Fields wrote:
> > By comparison on my little home server (Fedora, ext4, a couple WD Black
> > 1TB drives), with sync, that untar takes is 7:44, about 8ms/file.
> Ok, that is far m
On Tue, Jan 30, 2018 at 10:00:44AM +0100, Reindl Harald wrote:
> Am 30.01.2018 um 09:49 schrieb Terry Barnaby:
> > Untar on server to its local disk: 13 seconds, effective data rate: 68
> > MBytes/s
> >
> > Untar on server over NFSv4.2 with async on server: 3 minutes, effective
> > data rate: 4.
On Tue, Jan 30, 2018 at 08:49:27AM +, Terry Barnaby wrote:
> On 29/01/18 22:28, J. Bruce Fields wrote:
> > On Mon, Jan 29, 2018 at 08:37:50PM +, Terry Barnaby wrote:
> > > Ok, that's a shame unless NFSv4's write performance with small files/dirs
> > >
On Mon, Jan 29, 2018 at 08:37:50PM +, Terry Barnaby wrote:
> Ok, that's a shame unless NFSv4's write performance with small files/dirs
> is relatively ok which it isn't on my systems.
> Although async was "unsafe" this was not an issue in main standard
> scenarios such as an NFS mounted home di
Unless somebody's created an /etc/nfs.conf file, we should assume
they're still using /etc/sysconfig/nfs.
That shouldn't be difficult, and I don't see why we can't do that
indefinitely.
The goal should definitely be not to break any working setups on
upgrade.
--b.
On Mon, Jan 16, 2017 at 03:11:
ring correct limits.
> I don't know if this problem has been corrected now.
Probably not. This bug?:
https://bugzilla.redhat.com/show_bug.cgi?id=1364332
> 2016-11-29 21:19 GMT+01:00 Przemek Klosowski :
> > On 11/29/2016 12:58 PM, J. Bruce Fields wrote:
> >
> > I
On Tue, Nov 29, 2016 at 12:42:06PM -0500, Przemek Klosowski wrote:
> I was always impressed with the amount and quality of audio software in
> Linux. When it all works, and is driven by someone who knows what they're
> doing, it's essentially a high-end DAW production environment. If it all
> worke
On Mon, Nov 28, 2016 at 05:04:07PM -0500, J. Bruce Fields wrote:
> On Wed, Nov 23, 2016 at 08:28:12PM -0500, Stephen John Smoogen wrote:
> > On 23 November 2016 at 19:36, Samuel Sieb wrote:
> > > On 11/23/2016 07:39 AM, Chuck Anderson wrote:
> > >>
> > >>
On Wed, Nov 23, 2016 at 08:28:12PM -0500, Stephen John Smoogen wrote:
> On 23 November 2016 at 19:36, Samuel Sieb wrote:
> > On 11/23/2016 07:39 AM, Chuck Anderson wrote:
> >>
> >> Is it supposed to be supported to install RPMs onto NFS filesystems?
> >> Apparently NFSv3 doesn't support capabiliti
On Thu, Sep 08, 2016 at 01:37:49AM +0200, Guido Aulisi wrote:
> Il giorno mer, 07/09/2016 alle 00.54 +0200, Germano Massullo ha
> scritto:
> > Hi Guido, welcome! Have you already chosen a sponsor? [1]
> > Have a nice day
>
> Hi,
> I am looking for a sponsor and I have already made a review request
On Mon, Jul 18, 2016 at 03:59:09PM +0200, Ondřej Vašík wrote:
> Lennart Poettering píše v Po 18. 07. 2016 v 14:39 +0200:
> > Heya!
> >
> > I'd like to start a discussion regarding the "nobody" user on Fedora,
> > and propose that we change its definition sooner or later. I am not
> > proposing a f
On Tue, Aug 12, 2014 at 12:58:13AM -0400, Felix Miata wrote:
> Why when nothing is automounting nfs either as client or server does boot
> not proceed to completion without a 2+ minute pause while nfs-server fails
> to start?
Sounds like a bug. Is the failure to start expected?
> Exportfs never
On Tue, Dec 13, 2011 at 02:12:30PM -0500, Stephen Gallagher wrote:
> On Tue, 2011-12-13 at 14:06 -0500, J. Bruce Fields wrote:
> > On Mon, Dec 12, 2011 at 01:22:06PM -0800, Toshio Kuratomi wrote:
> > > To some extent I agree with both sgallagh's sentiment and the logical
On Mon, Dec 12, 2011 at 01:22:06PM -0800, Toshio Kuratomi wrote:
> On Mon, Dec 12, 2011 at 10:47:53PM +0200, Ville Skyttä wrote:
> > On 12/12/2011 10:29 PM, Stephen Gallagher wrote:
> >
> > > Patches should never be in the lookaside cache, because
> > > it is very difficult to view them.
> >
> >
37 matches
Mail list logo
