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

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

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

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,

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

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.

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

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

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

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

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 →

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 there.  I run

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't h

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 if

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

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

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't fu

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

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 i

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

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: >

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

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 exception

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

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

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

they >>>>>> believe 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

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

I should talk to about this? Whether 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. >> &

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

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

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

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

Re: Imaginary single quotes in ls ?

On 6/6/16 11:53 AM, Chris Adams wrote: > Once upon a time, Eric Sandeen <sand...@redhat.com> said: >> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=109b9220cead6e979d22d16327c4d9f8350431cc >> >> + ls now quotes file names unambiguously and app

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

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 been turned

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, if

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

; it was 1.42-ish: commit 3daf592646b668133079e2200c1e776085f2ffaf Author: Eric Sandeen sand...@redhat.com Date: Thu Feb 17 15:55:15 2011 -0600 e2fsprogs: turn off enforced fsck intervals by default The forced fsck often comes at unexpected and inopportune moments, and even enterprise

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

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 gb...@bzb.us 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

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 jwbo...@fedoraproject.org mailto:jwbo...@fedoraproject.org wrote: Is there any hardware out there that uses it? Aside from the hardware already mentioned in this thread, which Fedora

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 fed...@leemhuis.info wrote: Josh Boyer wrote on 07.10.2014 21:15: On Tue, Oct 7, 2014 at 2:24 PM, Josef Bacik jo...@toxicpanda.com wrote: [...]

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 has become

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 ago it was

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 image

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 records

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 Makefile up

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 wind

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 options. You

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 li...@colorremedies.com wrote: On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of

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 sand...@redhat.com 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? How well does thinp handle

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 zkabe...@redhat.com wrote: fsadm failed: 3 man fsadm DIAGNOSTICS On successful completion, the status code is 0. A status code of 2

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_check so I guess I should file

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 PM,

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 li...@colorremedies.com wrote: On Feb 27, 2014, at 3:02 PM, Jochen Schmitt joc...@herr-schmitt.de wrote: On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV wrote: A question I have is XFS

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 m...@cchtml.com wrote: Chris Murphy wrote: by default we put ext4 on LVM The tool works in this use-case unless something has broken it

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 idea at

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

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 of the few, along with, e.g

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 in the

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 guidlines. Renaming packages, censoring descriptions etc. in Fedora

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: $ git

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 ago, XFS did not even support shrinking

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 mr...@courier-mta.com 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

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 while,

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 that format

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

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 snit...@redhat.com 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

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 (the actual

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't tell us

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 you

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 515ms

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 rwhee...@redhat.com 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

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 sand...@redhat.com 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 differs with the various fs's. XFS and Btrfs

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 sand...@redhat.com 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

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 related

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

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 sand...@redhat.com wrote: On 5/8/13 9:21 AM, Mario Ceresa wrote: Dear all, When

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 mj...@srcf.ucam.org wrote: And if the maintainers feel more than justified in closing it again? Bugzilla isn't a discussion forum. If disagree

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 better choice if you want to interact

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 stat32, and sets .st_ino to 0, without generating EOVERFLOW

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 net...@crc.id.au 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

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 at 9:38 PM, Steven Haigh net...@crc.id.au wrote: Hi all, Firstly

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 (although semi-obvious when

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 nott...@redhat.com 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

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

On 2/19/13 6:48 AM, Petr Pisar wrote: On 2013-02-18, Eric Sandeen sand...@redhat.com wrote: Anyway, if you want to check your package(s) and maybe make them 64-bit-stat safe, the perl script above might help. It's more than just -DFILE_OFFSET_BITS=64, since you'll need to be sure

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

On 2/19/13 4:46 AM, Richard W.M. Jones wrote: On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote: XFS recently defaulted to allowing 32 bit inode numbers, and btrfs can let inode numbers creep past 2^32 as well. While most applications don't care one bit about st_ino returned from

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

On 2/19/13 9:32 AM, Jakub Jelinek wrote: On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote: (3) For my code that uses st_ino, I need to ensure this is never assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)? To be safe I'd use it in an u64 type, I guess

  1   2   >