Re: Helped wanted with tricky potential F41 blocker

On 10/18/24 5:54 PM, Adam Williamson wrote: > On Fri, 2024-10-18 at 17:10 -0500, Eric Sandeen wrote: >> Can anyone get a metadata image (e2image -Q /path/to/root/device >> image.qcow2) post-upgrade, >> before reboot tries to run fsck and fix things? > > I

Re: Helped wanted with tricky potential F41 blocker

On 10/18/24 5:54 PM, Adam Williamson wrote: > On Fri, 2024-10-18 at 17:10 -0500, Eric Sandeen wrote: >> Can anyone get a metadata image (e2image -Q /path/to/root/device >> image.qcow2) post-upgrade, >> before reboot tries to run fsck and fix things? > > I

Re: Helped wanted with tricky potential F41 blocker

On 10/18/24 4:42 PM, Adam Williamson wrote: > Hey folks! I'm sending up a flare for help with a potential F41 blocker > that looks pretty tricky. It is > https://bugzilla.redhat.com/show_bug.cgi?id=2318710 . > > The problem is fairly easy to reproduce. Install Fedora 40 or 41 Beta > with an ext4 r

Re: Restricting automounting of uncommon filesystems?

On 7/24/23 10:40 PM, Demi Marie Obenour wrote: On 7/24/23 15:11, Eric Sandeen wrote: On 7/23/23 7:22 PM, Steve Grubb wrote: On Saturday, July 22, 2023 2:01:34 AM EDT Matthew Garrett wrote: A discussion within Debian again brought up the problem that: 1) Automounting of removable media

Re: Restricting automounting of uncommon filesystems?

On 7/23/23 7:22 PM, Steve Grubb wrote: On Saturday, July 22, 2023 2:01:34 AM EDT Matthew Garrett wrote: A discussion within Debian again brought up the problem that: 1) Automounting of removable media exposes the kernel to a lot of untrusted input 2) Kernel upstream are not terribly concerned w

Re: Restricting automounting of uncommon filesystems?

On 7/24/23 10:00 AM, Daniel P. Berrangé wrote: On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote: ... I still believe that mounting should _not_ be automatic, though, because it could have side-effects (such as replaying the FS journal) that might not be wanted. To prevent p

Re: Restricting automounting of uncommon filesystems?

On 7/22/23 9:12 AM, Neal Gompa wrote: On Sat, Jul 22, 2023 at 9:53 AM Florian Weimer wrote: * Matthew Garrett: a) Does this seem like a good idea? b) If so, is dealing with it via udev rules the right approach? This way seems desktop-agnostic c) Where should it ship, and what should the proc

Re: Restricting automounting of uncommon filesystems?

On 7/22/23 7:57 AM, Michael Catanzaro wrote: I've been thinking about this for a while. The status quo is really awful. On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek wrote: A bigger problem I see, is that if a user plugins in a usb stick, expecting to make use of it, a

Re: btrfs loses 32-bit application compatibility after a while

On 7/14/23 4:47 PM, Fabio Valentini wrote: On Fri, Jul 14, 2023 at 10:45 PM Eric Sandeen wrote: On 7/14/23 6:53 AM, Florian Weimer wrote: * Neal Gompa: On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini wrote: On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer wrote: Fedora lists are

Re: btrfs loses 32-bit application compatibility after a while

On 7/14/23 6:53 AM, Florian Weimer wrote: * Neal Gompa: On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini wrote: On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer wrote: Fedora lists are hostile to upstream collaboration via cross-posting, so I can only forward this for your information. Thi

Re: filesystems and year 2038

On 4/4/22 2:51 PM, Justin Forbes wrote: > On Mon, Apr 4, 2022 at 11:47 AM Colin Walters wrote: >> >> Hi, creating a thread on this from: >> https://github.com/coreos/fedora-coreos-config/pull/1650 >> >> Basically I'd propose that not just our default images have y2038-compatible >> filesystem set

Re: Meaning of Size Directories

On 3/16/21 11:51 AM, John Reiser wrote: > On 3/16/21, David Howells wrote: >> John Reiser wrote: >> >>> See the manual page "man 2 getdents". >> >> Um, which bit?  I don't see anything obvious to that end. > > On that manual page: > = > The system call getdents() reads several linux_dirent st

Re: Meaning of Size Directories

On 2/25/21 6:56 PM, John Reiser wrote: >> Tools such as ls or stat report the size of a directory. Of course it is not >> the content size. >> stat -c %s  /home/sergio/.config >> 6550 >> >> What does 6550 mean in btrfs context? > > Regardless of filesystem type, the size of a directory is the sum

Re: btrfs and default page sizes (4k vs 64k)

On 9/16/20 10:22 AM, Benjamin Block wrote: > On Wed, Sep 16, 2020 at 09:31:50AM -0500, Eric Sandeen wrote: ... >> Sub-page block support in filesystems is not a wild, esoteric, unexpected >> feature. >> > > These kinds of problems are not really that rare acr

Re: btrfs and default page sizes (4k vs 64k)

On 9/15/20 7:29 PM, Neal Gompa wrote: > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler wrote: >> >> Daniel Pocock wrote: >>> One issue I've come across is that a btrfs filesystem can only be used >>> on hosts with the same page size as the host that created the filesystem >> >> Ewww! That alone shou

Re: Very strange compiler/linker related build failures in rawhide

On 7/24/20 1:31 AM, Fabio Valentini wrote: > Hi all, > > I'm starting to see various very strange kinds of build failures in > rawhide, that seem to have started with either of these updates (or a > combination of them): > > - annobin 9.21-1.fc33 → 9.22-1.fc33 > - binutils 2.34.0-6.fc33 → 2.34.0-

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/9/20 9:15 PM, Josef Bacik wrote: > On 7/9/20 9:30 PM, Eric Sandeen wrote: ... >>> This test is run constantly by us, specifically because it's the error >>> cases that get you.  But not for crash consistency reasons, because we're >>> solid ther

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/9/20 8:22 PM, Josef Bacik wrote: > On 7/9/20 7:23 PM, Eric Sandeen wrote: >> On 7/9/20 4:27 PM, Eric Sandeen wrote: >>> On 7/9/20 3:32 PM, Davide Cavalca via devel wrote: >> >> ... >> >>>> As someone on one of the teams at FB that has to deal wi

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/9/20 4:27 PM, Eric Sandeen wrote: > On 7/9/20 3:32 PM, Davide Cavalca via devel wrote: ... >> As someone on one of the teams at FB that has to deal with that, I can >> assure you all the scenarios you listed can and do happen, and they >> happen a lot. While we don

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/9/20 3:38 PM, Chris Murphy wrote: > On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote: >> On 7/9/20 2:11 PM, Josef Bacik wrote: >>>> From what I've gathered from these responses, btrfs is unique in that it >>>> is >>>> /expected/ that i

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/9/20 3:32 PM, Davide Cavalca via devel wrote: > On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote: >> However I have had bad kernels, power outages, loss of battery power >> (laptops on too long suspend) and other random reasons to force >> reboot >> a system. That has been the primary case

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/9/20 2:11 PM, Josef Bacik wrote: >> >>  From what I've gathered from these responses, btrfs is unique in that it is >> /expected/ that if anything goes wrong, the administrator should be prepared >> to scrape out remaining data, re-mkfs, and start over.  If that's acceptable >> for the Fedora

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/6/20 8:21 PM, Chris Murphy wrote: ... > Yes. Also in fuzzing there is the concept of "when to stop fuzzing" > because it's a rabbit hole, you have to come up for air at some point, > and work on other things. But you raise a good and subtle point which > is also that ext4 has a very good fsc

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/6/20 12:07 AM, Chris Murphy wrote: > On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen > wrote: >> >> On 7/3/20 1:41 PM, Chris Murphy wrote: >>> SSDs can fail in weird ways. Some spew garbage as they're >>> failing, some go read-only. I've seen both.

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/3/20 1:41 PM, Chris Murphy wrote: > SSDs can fail in weird ways. Some spew garbage as they're failing, > some go read-only. I've seen both. I don't have stats on how common it > is for an SSD to go read-only as it fails, but once it happens you > cannot fsck it. It won't accept writes. If it w

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/1/20 2:50 PM, Josef Bacik wrote: > On 7/1/20 2:24 PM, Matthew Miller wrote: >> On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew Jędrzejewski-Szmek wrote: >>> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for >>> F34 >>> could be good option. I know technically it is

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/2/20 4:44 PM, Josef Bacik wrote: > We're talking about this issue like it's reasonable that xfs and ext4 are > going to allow the user to get back a bunch of data they don't know is ok or > not. We're also talking about it like the user should be able to carry on his > happy merry way.  In

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/2/20 3:58 PM, José Abílio Matos wrote: > On Thursday, 2 July 2020 21.38.46 WEST Eric Sandeen wrote: >> 3 files in lost+found, -1 files gone/unreachable > > This last line from the xfs test seems suspicious (the -1 file gone). :-) It is weird, but it shows I didn'

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/1/20 12:50 PM, Chris Murphy wrote: ... > Integrity checking is highly valued by some and less by others. > Considering that we know hardware isn't 100% reliable, and doesn't > always report its own failures as expected, and hence why most file > systems now at least checksum metadata, it's n

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/1/20 9:24 AM, Josef Bacik wrote: > On 7/1/20 7:49 AM, Steven Whitehouse wrote: >> Hi, >> >> On 01/07/2020 12:09, Zbigniew Jędrzejewski-Szmek wrote: >>> On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote: Hi, On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/1/20 4:08 PM, Neal Gompa wrote: > On Wed, Jul 1, 2020 at 5:06 PM Eric Sandeen wrote: >> >> On 7/1/20 11:53 AM, Michael Catanzaro wrote: >>> On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel >>> wrote: >>>> Actually this split is a

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 7/1/20 11:53 AM, Michael Catanzaro wrote: > On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel > wrote: >> Actually this split is a godsend because you can convince anaconda to >> leave your home alone when reinstalling, while someone always seems too >> invent a new Fedora change that

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 6/29/20 1:47 PM, Josef Bacik wrote: Just to be clear here, the choice of XFS here is purely based on performance, not on the reliability of the file systems, right? (So it's not “all the really important data is stored in XFS”.) >>> >>> Yes that's correct.  At our scale every

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 6/29/20 12:44 PM, Mark Otaris wrote: > That’s one fewer reason not to use XFS then. It seems > Documentation/admin-guide/cgroup-v2.rst was not updated and still says > only ext2, ext4, and btrfs have writeback implemented. Interesting, thanks for the heads up - I'll get that fixed. Looks like

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 6/29/20 8:39 AM, Josef Bacik wrote: > On 6/29/20 5:33 AM, Florian Weimer wrote: >> * Josef Bacik: >> >>> That being said I can make btrfs look really stupid on some workloads. >>> There's going to be cases where Btrfs isn't awesome.  We still use xfs >>> for all our storage related tiers (think

Re: User experience issue on btrfs

On 6/29/20 3:19 AM, John M. Harris Jr wrote: > On Monday, June 29, 2020 1:09:16 AM MST Markus Larsson wrote: >> On 29 June 2020 08:26:21 CEST, "John M. Harris Jr" >> wrote: >>> On Sunday, June 28, 2020 5:37:08 PM MST Chris Adams wrote: >>> Once upon a time, John M. Harris Jr said:

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

On 6/29/20 1:31 AM, Mark Otaris wrote: > The master branch for cp now defaults to copy-on-write on filesystems > that support reflinks, which should make copies more efficient if > Fedora starts using btrfs: > https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=25725f9d41735d176d73a757430739

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

On 4/29/18 11:45 AM, Eric Sandeen wrote: >> Assuming that the plan is to leave it enabled in F-29 on branching and >> have it ship enabled in F-29 I agree, if the intention is to leave it >> enabled in rawhide and disable it on branching then the Change >> Proposal me

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

On 5/2/18 8:42 AM, Ian Pilcher wrote: > On 05/02/2018 08:25 AM, Eric Sandeen wrote: >> I've always seen the need for shrink as an indicator that someone had >> poor planning along the way, or insufficient tools for provisioning to >> start with.  Sure, there are exce

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

On 5/2/18 7:15 AM, Neal Gompa wrote: > On Wed, May 2, 2018 at 5:36 AM Marius Vollmer > wrote: > >> Neal Gompa writes: > >>> And there's still the fun restriction of XFS not being able to shrink. > >> But note that even ext4 can't shrink while being mounted. > > But it can shrink when it's not

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

On 4/30/18 1:16 PM, Neal Gompa wrote: > On Mon, Apr 30, 2018 at 2:14 PM Jason L Tibbitts III > wrote: > >>> "CW" == Colin Walters writes: > >> CW> I'd say it makes sense to revisit the default here globally in >> CW> Anaconda. > >> Maybe. Have the issues which made XFS less suitable for u

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

elieve it is ready to be turned on by default. >>>>>> >>>>>> I am not sure who in Red Hat I should talk to about this? Whether we >>>>>> should >>>>>> turn it on in the installer or in the mkfs.xfs command? >>>>>&g

Re: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

her we should >>> turn it on in the installer or in the mkfs.xfs command? >>> >>> Who should I be talking to?  To make this happen. >> I would speak to Eric Sandeen I believe he's the Red Hat maintainer >> (or one of them) of XFS. >> >> Peter > In

Re: getting kernel-devel added

On 9/12/17 10:49 AM, Matthew Miller wrote: > On Tue, Sep 12, 2017 at 11:35:08AM -0400, Ben Williams wrote: >> case A) Students are using Fedora on windows in a VM (Vbox in this >> case) for a class. they are required for said class to install the >> guest additions. they are constantly running into

Re: power management

On 4/9/17 4:39 AM, František Zatloukal wrote: > I had bad experience with enabling powertop' service - USB mice and > headphones don't work very well with that. But I am using tuned > (tuned-gtk) for few years and I didn't notice any issues > (top-battery) profile. I see that my Haswell laptop is u

Re: Fedora captive portal page changed output :(

On 12/2/16 7:10 PM, Paul Wouters wrote: > > Fedora runs a captive portal check page at: > > http://fedoraproject.org/static/hotspot.txt > > It used to return "OK\n". > > Now it returns "OK" without the newline. Seems like the file date is still well in the past (2015-12-15) and does not actual

Re: Orphaning apcupsd

On 6/22/16 2:24 PM, Jason L Tibbitts III wrote: >> "MH" == Michal Hlavinka writes: > > MH> Hi, my APC UPS died and as I won't be buying new APC UPS, I can no > MH> longer test and investigate bugs. So apcupsd is free for taking if > MH> anyone wants it. > > Well, I need it but I don't really

Re: Imaginary single quotes in ls ?

On 6/6/16 11:53 AM, Chris Adams wrote: > Once upon a time, Eric Sandeen said: >> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=109b9220cead6e979d22d16327c4d9f8350431cc >> >> + ls now quotes file names unambiguously and appropriate for use in a shell, >&

Re: Imaginary single quotes in ls ?

On 6/6/16 11:34 AM, Tom Hughes wrote: > On 06/06/16 17:32, Tom Hughes wrote: >> On 06/06/16 17:28, Adam Williamson wrote: >> >>> It showed up in F24 a few weeks back, at least in gnome-terminal. I >>> dunno if it's a g-t thing. >> >> No, it's ls. See --quote-name and --quoting-style in ls(1). > >

Re: Imaginary single quotes in ls ?

On 6/6/16 11:20 AM, Bernardo Sulzbach wrote: > On 06/06/2016 12:53 PM, Paul Wouters wrote: >> >> paul@thinkpad:/tmp/test$ touch foo bar baz >> paul@thinkpad:/tmp/test$ touch "touch and go" >> paul@thinkpad:/tmp/test$ ls -l >> total 0 >> -rw-rw-r--. 1 paul paul 0 Jun 6 11:48 bar >> -rw-rw-r--. 1 pa

Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

On 5/1/15 2:18 AM, Till Maas wrote: > On Thu, Apr 30, 2015 at 05:11:20PM -0700, Adam Williamson wrote: > >> "What doesn't work is rtc-in-local in early-boot, that's all. And that >> doesn't matter really, except if you are crazy enough to manually >> enable time-based fsck in ext234, which has bee

Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

s in recent weeks or months to cause the > current boot delays these fscks consistently impose. well, not since time began; it was 1.42-ish: commit 3daf592646b668133079e2200c1e776085f2ffaf Author: Eric Sandeen Date: Thu Feb 17 15:55:15 2011 -0600 e2fsprogs: turn off enforced fsck

Re: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

On 4/30/15 7:58 PM, Matthew Miller wrote: > On Thu, Apr 30, 2015 at 05:22:20PM -0700, Andrew Lutomirski wrote: >> Maximum mount count: 21 >> Last checked: Mon Apr 6 10:42:37 2015 >> Check interval: 15552000 (6 months) > > The default is definely now 0, but you're right,

Orphaning NCID (Caller ID server/client)

I've not been keeping up with NCID (a caller id server/client system; pretty neat, being able to send caller ID to mythtv, desktop notifications, etc). It needs some systemd love, and has newer upstream releases. I was using it on a CentOS 6 server, and have no good way to test it on newer releas

Re: Why isn't F2FS support in the Kernel?

On 12/22/14 12:12 PM, Gerald B. Cox wrote: > > On Mon, Dec 22, 2014 at 9:32 AM, Josh Boyer > wrote: > > > Is there any hardware out there that uses it? > > Aside from the hardware already mentioned in this thread, which Fedora > doesn't run on, ther

Re: Why isn't F2FS support in the Kernel?

On 12/22/14 8:16 AM, Josh Boyer wrote: > On Sun, Dec 21, 2014 at 11:09 PM, Gerald B. Cox wrote: >> Yes, I looked at that bug report and the somewhat terse response. I thought >> I'd post here first before I went the bugzilla route. >> >> Based upon the information I discovered tonight it seems a

Re: btrfs as default filesystem for F22?

On 10/8/14 8:39 AM, Thorsten Leemhuis wrote: > On 08.10.2014 14:50, Josh Boyer wrote: >> On Wed, Oct 8, 2014 at 1:52 AM, Thorsten Leemhuis >> wrote: >>> Josh Boyer wrote on 07.10.2014 21:15: On Tue, Oct 7, 2014 at 2:24 PM, Josef Bacik wrote: [...] >>> http://kernel.opensuse.org/cgit/ke

Re: btrfs as default filesystem for F22?

On 10/6/14 9:26 AM, Josef Bacik wrote: > Obviously we aren't in xfs/e2fsprogs territory, but it'll fix 90% of > the problems and then the other 10% are just a matter of having an > example to work off of. Thanks, > > Josef Josef, just as a datapoint: after corrupting 32k random bytes on a 2G ima

Re: btrfs as default filesystem for F22?

On 10/6/14 7:45 AM, Ralf Corsepius wrote: > On 10/06/2014 02:29 PM, Gene Czarcinski wrote: > >> Now, there is another question which has not been voiced: what is >> the "plan" for filessystems in Fedora (and by implication RHEL)? >> Is it BTRFS? Or, perhaps is it LVM with XFS? IIRC, some time ag

Re: btrfs as default filesystem for F22?

On 10/6/14 8:50 AM, Ric Wheeler wrote: > On 10/06/2014 08:54 AM, Josef Bacik wrote: >> >> Well that's exactly what it is, go away I'm busy with other stuff >> :). The fact is I'm the only one who can drive btrfs as the >> default filesystem feature in Fedora, and since I've left Red Hat >> that h

Re: Non-responsive maintainer Russell Cattelan

I know Russell - I'll reach out to him. I also like xxdiff ;) He's probably quite willing to turn this over to you. -Eric On 8/1/14, 4:39 AM, Christopher Meng wrote: > Hi all, > > I'm unable to contact Russell Cattelan (cattelan{at}xfs[dot]org) for > almost one year[1]. I vetted his login reco

Re: unsigned char vs. signed char

On 7/15/14, 11:40 AM, Orion Poplawski wrote: > Did you know that "char" defaults to "signed char" on x86 but "unsigned char" > on ppc and arm? I didn't. > > Just a heads up. > I did, because due to XFS's history, it maked an assumption that's not true on x86. We had -funsigned-char in the Ma

Re: default file system, was: Comparison to Workstation Technical Specification

On 3/4/14, 3:43 PM, Ric Wheeler wrote: > On 03/04/2014 11:26 PM, Przemek Klosowski wrote: >> On 02/28/2014 03:45 PM, Adam Williamson wrote: >>> As a server WG member I voted +1 on XFS as I have no particular objection >>> to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to

Re: default file system, was: Comparison to Workstation Technical Specification

On 3/3/14, 7:34 PM, Chris Adams wrote: > Once upon a time, Eric Sandeen said: >> The shrink/grow thing was clever, but also a bit abusive from a filesystem >> design point of view. > > How does it compare to the suggested alternative, LVM thin provisioning? > Ho

Re: default file system, was: Comparison to Workstation Technical Specification

On 3/3/14, 5:57 PM, Jon wrote: > On Sat, Mar 1, 2014 at 3:18 PM, Chris Murphy wrote: >> >> On Mar 1, 2014, at 1:19 PM, Jon wrote: >> >>> The inability to shrink or reduce XFS is rather disappointing. I've >>> seen a few sarcastic remarks along the lines of (paraphrased): why >>> would anyone ever

Re: default file system, was: Comparison to Workstation Technical Specification

On 3/3/14, 3:16 PM, Matthias Clasen wrote: > On Mon, 2014-03-03 at 16:16 +0200, Ric Wheeler wrote: > > >> I am fine with something like what is proposed by Steve above - let users >> have >> the GUI present an option that gives preference to the default without >> totally >> hiding other opti

Re: lvresize and XFS, was: default file system

On 2/28/14, 8:12 AM, Eric Sandeen wrote: > However, I see that (at least my copy of) fsadm requires xfs_check, > which has been deprecated upstream in favor of xfs_repair -n. > xfs_check doesn't scale, and xfs_repair -n performs the same > tasks. > >> XFS_CHECK=xfs_chec

Re: lvresize and XFS, was: default file system

On 2/28/14, 7:54 AM, Zdenek Kabelac wrote: > Dne 28.2.2014 14:37, Chris Murphy napsal(a): >> >> On Feb 28, 2014, at 1:33 AM, Zdenek Kabelac wrote: >> >> > fsadm failed: 3 >>> >> >>> man fsadm >>> >>> DIAGNOSTICS >>>On successful completion, the status code is 0. A status code of

Re: default file system, was: Comparison to Workstation Technical Specification

On 2/27/14, 10:53 PM, James Wilson Harshaw IV wrote: > > On 02/27/2014 11:20 PM, Chris Murphy wrote: >> On Feb 26, 2014, at 12:53 PM, Michael Cronenworth wrote: >> >>> Chris Murphy wrote: by default we put ext4 on LVM >>> The tool works in this use-case unless something has broken it recentl

Re: lvresize and XFS, was: default file system

On 2/27/14, 4:40 PM, Chris Murphy wrote: > > On Feb 27, 2014, at 3:32 PM, Chris Murphy wrote: > >> >> On Feb 27, 2014, at 3:02 PM, Jochen Schmitt wrote: >> >>> On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV wrote: A question I have is XFS worth it? >>> >>> I have done so

Re: default file system, was: Comparison to Workstation Technical Specification

On 2/27/14, 4:08 PM, James Wilson Harshaw IV wrote: > Interesting. If someone could confirm that this remains true with Fedora 20, > it would be extremely beneficial. With details, please, as Chris requested. "doesn't cooperate" is not enough to go on. ;) Thanks, -Eric > On 02/27/2014 05:02

Re: May I file 1000 bugs aka upstream test suite tracking

On 2/21/14, 9:25 AM, Daniel P. Berrange wrote: > On Fri, Feb 21, 2014 at 04:19:29PM +0100, Miroslav Lichvar wrote: >> On Fri, Feb 21, 2014 at 02:50:12PM +, Daniel P. Berrange wrote: >>> On Fri, Feb 21, 2014 at 09:38:56AM -0500, Josh Boyer wrote: Personally, I don't think %check is a good i

Re: Drawing lessons from fatal SELinux bug #1054350

On 1/23/14, 6:37 PM, Kevin Kofler wrote: > Eric Sandeen wrote: >> If the solution to every serious bug that slips through the cracks of a >> release is to disable the package, over time we may not have much left in >> Fedora. > > But SELinux is the one package (OK, one

Re: Drawing lessons from fatal SELinux bug #1054350

On 1/23/14, 5:55 PM, Kevin Kofler wrote: > * We are enabling SELinux enabled (enforcing) by default, a tool designed to > prevent anything it does not like from happening. (Reread this carefully: > The ONLY thing that tool is designed to do at all is PREVENT things. It does > not have a SINGLE f

Re: Packages have "proxy" word.

On 11/2/13 11:48 AM, Basil Mohamed Gohar wrote: > On 11/02/2013 12:46 PM, Eric Sandeen wrote: >> On 11/2/13 10:50 AM, Kevin Kofler wrote: >>> مصعب الزعبي wrote: >>>> Then do new rule to write "proxies" instead of proxy, at Fedora packaging >>>

Re: Packages have "proxy" word.

On 11/2/13 10:50 AM, Kevin Kofler wrote: > مصعب الزعبي wrote: >> Then do new rule to write "proxies" instead of proxy, at Fedora packaging >> guidlines. > > Renaming packages, censoring descriptions etc. in Fedora at the whims of > governments (of countries Fedora isn't supposed to be exported to

Re: custom kernel, how to revert patch

On 10/9/13 10:25 AM, Chris Murphy wrote: > This http://fedoraproject.org/wiki/Building_a_custom_kernel has > ApplyPatch examples in the spec file, which works fine. Is there an > inverse command? Or do I need to do it manually with patch -p0 -R < > ? You could generate the reverse patch with: $ g

Re: Default boot/root filesystem

On 9/9/13 10:56 AM, Till Maas wrote: > On Sat, Sep 07, 2013 at 05:35:05PM -0500, Eric Sandeen wrote: > >> If people want to switch the Fedora default to XFS, I'll gladly file >> the feature. :) > > Why is XFS better than ext4. When I checked a few months ag

Re: Default boot/root filesystem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/6/13 5:48 PM, Sam Varshavchik wrote: > According to this: > > http://www.serverwatch.com/server-news/where-is-red-hat-enterprise-linux-7.html > > RHEL7 will use XFS for the default boot/root. > > I could certainly have been out of town, for a w

Re: Default boot/root filesystem

On 9/7/13 3:47 AM, Chris Murphy wrote: > > On Sep 7, 2013, at 12:48 AM, Sam Varshavchik wrote: > >> According to this: >> >> http://www.serverwatch.com/server-news/where-is-red-hat-enterprise-linux-7.html >> >> RHEL7 will use XFS for the default boot/root. > > The article doesn't make it clear

Re: Suggestion: bmap files and bmaptool

On 8/16/13 3:46 AM, Artem Bityutskiy wrote: >> Another approach which might (?) be more robust, is to somehow encode >> > that sparseness in a single file format that can be >> > transported/compressed/copied w/o losing the sparseness information, >> > and another tool to operate efficiently on tha

Re: Suggestion: bmap files and bmaptool

On 8/13/13 8:58 AM, Artem Bityutskiy wrote: > # Make the image to be sparse > $ cp --sparse=always Fedora-x86_64-19-20130627-sda.raw > Fedora-x86_64-19-20130627-sda.raw.sparse > > # Generate the bmap file > $ bmaptool create Fedora-x86_64-19-20130627-sda.raw.sparse -o > Fedora-x86_64-19-20130627

Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

On 7/31/13 12:08 PM, Chris Murphy wrote: > > On Jul 31, 2013, at 8:32 AM, Mike Snitzer > wrote: > >> But on the desktop the fedora developers need to provide sane >> policy/defaults. > > Right. And the concern I have (other than a blatant bug), is the F20 > feature for the installer to create t

Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

On 7/27/13 11:56 AM, Lennart Poettering wrote: > On Fri, 26.07.13 22:13, Miloslav Trmač (m...@volny.cz) wrote: > >> Hello all, >> with thin provisioning available, the total and free space values >> reported by a filesystem do not necessarily mean that that much space >> is _actually_ available (t

Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

On 7/26/13 3:13 PM, Miloslav Trmač wrote: > Hello all, > with thin provisioning available, the total and free space values > reported by a filesystem do not necessarily mean that that much space > is _actually_ available (the actual backing storage may be smaller, or > shared with other filesystems

Re: Bad file access on the rise

On 6/7/13 3:06 PM, Steve Grubb wrote: > On Friday, June 07, 2013 08:42:09 PM Matthew Garrett wrote: >> On Fri, Jun 07, 2013 at 03:35:28PM -0400, Steve Grubb wrote: >>> So far, the discussion has focused on pulseaudio. But what about the >>> O_NOATIME issue? >> >> Without further analysis, it doesn'

Re: Bug cloning considered harmful

On 6/3/13 11:06 AM, Adam Williamson wrote: > Hi, folks. Just wanted to throw out a random note on something that > often irks me. > > Next time you're thinking about cloning a bug: think twice. I've found > that it's rarely the case that cloning a bug is really the right thing > to do. > > When y

Re: when startup delays become bugs

On 5/17/13 5:39 PM, Chris Murphy wrote: > > On May 17, 2013, at 3:53 PM, Eric Sandeen wrote: > >>>> On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote: >>>> >>>>> There have been no crashes, so ext4 doesn't need fsck on

Re: when startup delays become bugs

On 5/17/13 5:29 PM, Chris Murphy wrote: > > On May 17, 2013, at 3:56 PM, Eric Sandeen wrote: > >> On 5/17/13 3:58 PM, Chris Murphy wrote: >>> >>> Seems some extra complexity is needed anyway since the way to deal >>> with file system problems differ

Re: when startup delays become bugs

On 5/17/13 3:58 PM, Chris Murphy wrote: > > On May 17, 2013, at 2:38 PM, Ric Wheeler wrote: > >> On 05/16/2013 02:39 PM, Lennart Poettering wrote: >>> On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote: >>> There have been no crashes, so ext4 doesn't need fsck on every boo

Re: when startup delays become bugs

On 5/17/13 3:38 PM, Ric Wheeler wrote: > On 05/16/2013 02:39 PM, Lennart Poettering wrote: >> On Thu, 16.05.13 12:20, Chris Murphy (li...@colorremedies.com) wrote: >> >>> There have been no crashes, so ext4 doesn't need fsck on every boot: >>> >>>4.051s systemd-fsck-root.service >>>

Re: ext4 - scsi: storvsc: avoid usage of WRITE_SAME

torvsc: avoid usage" 3e8f4f4065901c8dfc51407e1984495e1748c090 [SCSI] storvsc: avoid usage of WRITE_SAME [root@host linux-2.6]# git describe --contains 3e8f4f4065901c8dfc51407e1984495e1748c090 v3.9-rc1~21^2~7 -Eric > Mario > > On 8 May 2013 16:28, Eric Sandeen wrote: >> On 5/8/13 9:21 AM, Mar

Re: ext4 - scsi: storvsc: avoid usage of WRITE_SAME

On 5/8/13 9:21 AM, Mario Ceresa wrote: > Dear all, > When accessing a VHDX disc with a f18 VM (hyperv) with kernel > 3.8.8-202 x86_64 I have tons of errors like: > > Add. Sense: No additional sense information > hv_storvsc vmbus_0_12: cmd 0x41 scsi status 0x2 srb status 0x6 > > I believe it is re

Re: Do you think this is a security risk and if not is it a bad UI decision?

On 5/3/13 11:30 PM, Matthew Garrett wrote: > On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote: >> On 5/3/13 10:58 PM, Matthew Garrett wrote: >>> No, this isn't the most appropriate mailing list for the discussion - >>> anaconda-devel-list is a bette

Re: Do you think this is a security risk and if not is it a bad UI decision?

On 5/3/13 10:58 PM, Matthew Garrett wrote: > On Fri, May 03, 2013 at 08:52:25PM -0700, Dan Mashal wrote: >> On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett wrote: >>> And if the maintainers feel more than justified in closing it again? >>> Bugzilla isn't a discussion forum. If disagree with a deli

Re: 64-bit stat (or not) in 32-bit Fedora binaries

On 4/3/13 3:49 AM, Florian Weimer wrote: > On 02/19/2013 12:15 AM, Eric Sandeen wrote: >> On 2/18/13 5:11 PM, John Reiser wrote: >>> It would be useful to have a "backward compatibility" LD_PRELOAD shared >>> library which intercepts the caller of stat3

Re: XFS and trim

On 4/2/13 9:26 AM, Steven Haigh wrote: > On 03/04/13 01:08, Eric Sandeen wrote: snip >> I wonder if we should add something to the remount path to printk >> when a non-remountable option is encountered; I might look into >> that, otherwise it's a little surprising (alt

Re: XFS and trim

On 4/2/13 9:30 AM, Ric Wheeler wrote: > On 04/02/2013 10:26 AM, Steven Haigh wrote: >> On 03/04/13 01:08, Eric Sandeen wrote: >>> On 4/1/13 5:26 PM, Steven Haigh wrote: >>>> On 04/02/2013 12:19 AM, Josef Bacik wrote: >>>>> On Sat, Mar 30, 2013 a

Re: XFS and trim

On 4/1/13 5:26 PM, Steven Haigh wrote: > On 04/02/2013 12:19 AM, Josef Bacik wrote: >> On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh wrote: >>> Hi all, >>> >>> Firstly, Please CC me into replies as I'm not subscribed to this list. >>> >>> I'm trying to confirm that Fedora 18 has enabled trim for X

Re: 64-bit stat (or not) in 32-bit Fedora binaries

On 2/20/13 8:23 AM, Chris Adams wrote: > Once upon a time, Bill Nottingham said: >> Florian Weimer (fwei...@redhat.com) said: >>> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes >>> pretty close to an ABI bump. But considering the numbers, I wonder >>> if it's the right thing t

  1   2   >